Agile project management helps overcome IT obstacles
Traditional project management can ruin the best-intentioned IT efforts. It's time to get flexible and interact with stakeholders using Agile methods.
Early in my IT project management and leadership career, I learned three incredibly important lessons:
1. No one knows what they want until they see it.
2. Once they see it, they will want to change it.
3. At best, large projects will be challenged; at worst, they will fail.
Learning these lessons shaped how I plan and manage every type of IT project since then. I've shifted away from traditional project management methods and toward what is now called Agile project management, which emphasizes flexibility and interaction with empowered stakeholders. Here's how Agile project management has worked for me, and how you can use Agile methods for greater project success.
1. No one knows what they want until they see it.
I once led a project to develop a new Web application. I spent days gathering requirements from the project's stakeholders. We discussed and mapped out the entire process and information flow. We sorted through the exceptions we had to handle. We then created a magnificent document that precisely captured everything we had discussed.
Niel Nickolaisen
My stakeholders reviewed and approved this document, and my team set about building the associated application. Sometime later, we delivered an application that matched the approved requirements document exactly. The intended users of this fine piece of software opened the application, spent some time navigating about, and then told me that we had gotten it all wrong.
Wrong? How could that be? We had documented the requirements. The users had approved these requirements. We had built to the requirements. How could we have gotten it wrong?
Because no one knows what they want until they see it.
There is a big difference between what someone reads and approves in a document, and how they envision the application. The only way to avoid the wasted effort and lost time of this mismatch is to replace comprehensive requirements documentation with something users can see and use.
Using Agile methods, we meet with our stakeholders and have them define their requirements and prioritize which requirements they want to see and use first. We then deliver an early version of the product and have them give us feedback -- not feedback on a document, but feedback on something they can actually see and use.
2. Once they see it, they will want to change it.
Things change. Sometimes things change a lot. In order for IT projects to keep pace with change, our project management methods need to expect that change will happen. This is in stark contrast to more traditional approaches to project management.
Using traditional methods, we punish anyone who wants a change. We require scope changes or requirements changes to go through some kind of change review and approval. We require those requesting the changes to justify the disruption their change will create to our well-defined project plans.
These attempts to eliminate change, however, ignore the reality that sometimes changing scope or changing requirements is the right thing to do. In other words, if the target moves, so should our aim.
In practice, we can become more Agile if we break our projects into phases. At the end of each phase, we can ask ourselves what needs to change. Does a changing technology mean we should revise our plans? Does changing competition mean that we should revise our requirements? Does a process modification mean that we should revise our business rules? If so, we can make the change as part of the next project phase.
3. Large projects will be challenged. And they may fail.
Many years ago I read an interesting piece of research that showed that the larger an IT project, the more likely it was to be "challenged" (over budget, late or off-target). Even worse, once a project got to a certain (large) size, project failure was a certainty.
Agile resources
Agile project management, from Agile to waterfall
Choosing a management approach that clarifies Agile project completion
Why Agile projects pose challenges for enterprise project managers
Small projects, on the other hand, almost always succeeded, according to this research. Because I wanted to have successful projects and avoid challenged and failed projects, I decided I needed to transform all IT projects into small projects.
I now break all projects into smaller pieces. If we think a project will last about nine months, we break it into a series of two- to three-month chunks. It isn't as hard as you might think to break projects into pieces. For example, if you are planning a network upgrade, your first chunk might test the new network gear at one location or rewire part of the building or build a lab to test the core switch. The next chunks will vary depending on the results of the first chunk.
I take this chunking approach to everything I do. In a business intelligence (BI) project, we start with one department of one business unit. Doing this narrows our focus and reduces our risks. After we have successfully figured out how to deliver usable BI tools, we expand into other parts of the business. If we are implementing a new Software-as-a-Service application, we start off with a pilot group of users before we ever consider taking the project across the organization.
I was using Agile methods long before I ever heard the term. I use them because they work. You might find that they work, too.
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 [email protected].
