“You have to ensure that senior management clearly buys into the fact that application security should be the No. 1 priority, because without that I can guarantee that you will get hacked.” How can you keep your security one step ahead? SD Times, Oct 2011, page 75.

Security is our number one priority. Except for quality which is our number one priority, right along with speed to market which is our number one priority. Also, getting that project plan right especially the estimates is our number one priority. In the Air Force, when I was a computer security officer, the flight crews would remind me that the mission always comes first, then comes “you guys” in security, safety, etc. So, what then is a project manager’s number one priority?

Beats me, but I can tell you what I’ve done in successful projects. Even as a consultant, I rarely walk into any situation with a “this is what needs to be your top priority” position. Instead in any new job or project I first just wade in and experience what all is going on. The purpose is to determine what is taking place right now and more importantly what is causing the problems that are observed right now. This second part, seeing the real causes, is both hard and is the most important thing I do, in my experience. It drives everything else we do from that point on.

While I would love to get everything right the first time, it rarely works out that way. Instead, I try to stabilize the project or organization so it is not so chaotic (e.g., daily emergency meetings, daily change of plan and direction, etc.). This stability is generally achieved by making a few key decisions usually based upon fundamental principles. Typically, these have looked like:

1. Write it down and say “this is the strategy and plan.” Publish it, repeat it, point people towards it. The plan might fit on one slide. It inevitably has too few details. It is usually the current high level parameters of the project (delivery date, budgets, critical requirements, etc.). The purpose is for that plan to become the definitive guidance on what everyone (worldwide) is to be doing. As we (ok, as I) get smarter, the plan is expanded and updated. The plan is used and referred to every day. It does not get changed unless the change goes through me. Everyone has the same visibility into the plan. There is no special group with extra insights into an inner circle plan.

2. Ask for a rock solid defect fix rather than a fix by “Friday.” Quality first so we have something stable to work with going forward. This appears to sacrifice speed/schedule and might seem to violate a promise that had been made, possibly to a critical customer.

3. Give the team breathing room. I set a minimum cycle time we’ll need to do something, even when we often do many things much faster. This has included setting 90 days as the soonest we would deliver a defect fix to a customer, even a cosmetic change on a screen (this was in the 1980s!). Similarly, I set nine months in one case as the minimum schedule we would need to complete any new software project.

4. Move a manager or well known expert out of their apparent area of expertise and into something unrelated. This took an experienced or influential or relied upon person and made them no longer available to everyone. I’ve found that some people, as good as they seem to be, have habits and behaviors that otherwise cause teams and projects to underperform.

Some of these actions look pretty draconian. In every case, they were focused on dealing with the root cause of a problem that was preventing the team or project from performing as promised as to schedule, quality or cost. In every case, it was to stabilize the environment and remove negative influences. These actions were usually directed at bad management practices. Once these external or even internal influences were removed, the project teams soared. In most cases, the decision or rule used to stabilize the project or team were eventually relaxed, rescinded or otherwise modified to something more in alignment with our now demonstrated performance.

As project managers, our first priority is rarely something we determine in a vacuum (i.e., vendor whitepaper, industry study, published article, individual opinions, etc.). Instead, in my experience, it is something that is based upon the current observed circumstances and performance of our project team. This tells us what our priorities need to be. We still have to be aware of everything else that needs to be done — which is our core strength as project managers — and these should be scheduled to be done at an appropriate level of effort. As the Air Force crews would remind me: we need to be able to do the mission first, otherwise there is no need for any of that other stuff.

How do you get or set the priorities in your projects?