Project management competency built on agile methods, risk mitigation

Niel Nickolaisen outlines how to develop project management competency around agile methods, risk mitigation and transparency.

I am building project management competency within my IT team. Historically, whoever was a project's technical

lead also did the project management tasks. 

Niel Nickolaisen
The Real Niel
Niel Nickolaisen

As our systems and processes became more interdependent, however, we started to get blindsided by unknown dependencies and ripple effects.

When I decided to make my IT team competent in project management, I figured it would be pretty straightforward: Train or hire some good project managers and let them do their work. 

But as I started to think about the role I really needed in my IT organization, it became apparent that building project management competency wouldn't be that simple. As I reflected on my project management needs, I identified three nontraditional project management characteristics that were critical to my success:

  • Agile or iterative methods must be the basis of project management.
  • Project management must manage and mitigate risks proactively.
  • Projects and their status must be visible.

Agile or iterative methods for project management

As I've previously described, agile methods help solve a range of traditional IT project problems. We should break every IT project into smaller, more manageable pieces. We then can adapt for changes at the end of each piece. This advice should not, however, imply that we are free to change everything. One of the most effective agile project management methods is to define what will be done in the current piece, then let the team deliver that piece. If someone changes his mind, we consider those changes when we plan the next piece.

Agile project management must mitigate risks proactively

Some years ago, I began thinking about managing risk in a more conscious, proactive way. Traditionally, project management mitigates risk with tight, controlling processes. Such processes, however, have difficulty co-existing with agile methods -- methods that want to adapt to change.

We live in an environment in which everyone wants access to everything -- right now!

My approach to proactive risk management begins during the initial project planning. I create a profile of the project's risks that divides them into three categories: delivery risks (the risks to being on-time, on-budget and on-target); business case risks (the risks of incorrect assumptions); and collateral-damage risks (when the project delivers what was promised but has some terrible ripple effects on something else).

Once we have identified risks in these three categories, we determine their source. Are they due to uncertainty? (There are business case risks, for example, because the expected benefits are a wild guess.) Or are they due to complexity? (There are delivery risks, for example, because we are using an incredibly complex integration technology.)

With the risks' categories and sources defined, we next identify specific project tasks that will confront and mitigate them. In general, if the source of the risk is uncertainty, we use agile or iterative methods to reduce those risks. For example, we would do a small pilot to define our as-yet-uncertain benefits. If the source of the risk is complexity, however, we decouple and simplify what we can. At the end of each project piece or iteration, we then update our risk profile and mitigation steps -- again, anticipating that risks, like everything else, will change.

Projects and their status must be visible

One of the adages of continuous process improvement is that we should be able to tell the status of everything simply by looking. This same adage applies to project management competency. We live in an environment in which everyone wants access to everything -- right now! Why, then, would I make my project stakeholders wait for me to gather, document and distribute information about their projects? Instead, I should have a way for project status to be visible -- meaning that stakeholders can tell the status just by looking -- in near-real time.

How is this possible? First, I should keep my project status requirements to a bare minimum. Otherwise, status reporting can be onerous -- and onerous tasks have a tendency of not being done in real time. Second, I should make project status information accessible. We use visual displays (those "agilists" among us should think of typical information radiators), as well as simple technology dashboards that project teams can update and that stakeholders can access -- again, without too much trouble.

Project management plays a crucial role in our success, but it has to be as adaptable as our organizations are requiring us to be. I have neither time nor room in my life for bureaucratic project management processes. I get what I need when I do iterative projects that manage risks proactively and are visible to any and all interested stakeholders.

Niel Nickolaisen is CIO at Western Governors University in Salt Lake City. He is a frequent speaker, presenter and writer on IT's dual role enabling strategy and delivering operational excellence. Write to him at

This was first published in April 2012

Dig deeper on IT project management and portfolio management



Enjoy the benefits of Pro+ membership, learn more and join.



Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to: