In software development, there is family of “iterative development” methodologies, including Agile, RAD, Lean, Extreme Programming, and others, all designed to adapt quickly to a changing business environment. They measure progress on the rapid and frequent delivery of working software. Many excellent resources exist that explain these techniques in depth; discussion of these is beyond the scope of this paper.
At their core, Agile methodologies are interactive in nature, breaking down complex tasks into small, time-bound activities called “cycles.” These blocks of work are then prioritized based on the customer’s needs. The cycle begins with the development team and customer working closely together to define requirements for the top priority item, after which coding and testing commence. Most importantly, at the end of each cycle, a usable component is delivered to the customer for acceptance—thus, each cycle is an opportunity to provide value to the customer.
Because the Agile methodology is iterative in nature, each cycle builds on the lessons of the ones that came before it. This is true for both the development team, which can adjust programming approach, and the customer (business team), who can adapt to changing business conditions.
A key tenet of Agile is that the development team and customer collaborate closely on each cycle. The business team has the opportunity to refine or outright change their priorities or requirements entering the cycle. This approach recognizes that the business is also trying to plan for an unknowable future and allows the development team to adapt to the changing priorities and needs of the business.
In a development effort using a 2-week cycle time and running for 1 year, it is not unreasonable to expect that the development team could complete 20 cycles and thus have 20 opportunities to deliver value to the customer—each time aligned with the customer wants most. It is easy to see how this is an attractive approach.
Suggested Read: Agile planning process and methods
The philosophy is codified in The Agile Manifesto (Beck et al., 2001):
We are uncovering better ways of developing software by doing it and helping others to do it.
Through this work we have come to value:
- Individuals and interactionsover processes and tools
- Working softwareover comprehensive documentation
- Customer collaborationover contract negotiation
- Responding to changeover following a plan
That is, while there is value in the items on the right, we value the items on the left more.
Although Agile is focused on software development and is not a generic project management methodology, it provides some excellent lessons about working with a customer. These lessons clearly apply to the concept of managing customer expectations and thereby extend to measuring project success.
Ask Not How Your Phases Define Value, But How Value Defines Your Phases
Consider, then, the Agile project concept above—20 times during a year the development team had an opportunity to understand and then meet the customer’s expectations. This means there were 20 measureable events by which one could evaluate project performance against cost, schedule, scope, and quality. The following example may be extreme, but it illustrates a powerful concept: Imagine decomposing a project into manageable pieces, and for each piece applying planning best practices; however, when breaking the project apart, rather than doing it by phase, time, or even deliverable, do it instead by things that provide the customer with something he or she can use, something of value. Further, imagine doing it in such a way that the customer has some level of input on what is worked on next. On such a project it would be appropriate to make commitments (set baselines) for each stage of the project, one by one, and to measure and take credit for the success or failure of each commitment on its own. Planning a 2-year project in this way might enable the project manager to have a dozen different “success/failure” moments, and at the end of the project, the project manager could be evaluated on how many of those commitments were met versus missed.
Using this type of thinking, the construction of a house might be decomposed differently. Instead of breaking the project down into products aligned by functional groups (concrete, framers, finishers, landscapers), it could be decomposed into products that provide value to the end customer. The homeowner would find little value in the framed-up shell, so why choose that as a phase? The customer would find value in usable deliverables such as a fully enclosed (and thus weatherproof) structure, working utilities (plumbing, electricity), finished rooms that are move-in ready, and landscaped property with curb appeal. At each of those points there would be something new the customer could use, even if the project ended at that point.
Also Read: Agile and SAAS
In addition, the customer may be able to rearrange the order in which some things happen to suit his own needs. For instance, the customer may want to reconsider his choice of bathroom fixtures, so pushing the interior finish work back may allow him time to make those decisions. Imagine that the customer designed the house himself or herself and was submitting photos to an architectural magazine. A looming submission deadline might find him wanting a fully landscaped yard outside the completed structure before having working utilities and finished rooms. Giving the customer some control over the priority of the tasks and input into their design while delivering things of value to him will surely improve customer satisfaction with the final product.
I have been able to successfully apply these concepts on a real-world IT project. We were addressing an audit finding and senior management had committed that the fix would be in place in 6 months. We began in the traditional way, scoping out the problem and gathering customer requirements. We developed a design to meet the needs and then decomposed it into software modules. Working backwards from our fixed date we determined how much time we had to build each module and presented a high-level “waterfall-style” plan to the executives to gain commitment. Once coding began we brought the customers into multiple meetings each week to collaborate on the solution. We would probe, challenge, discuss, and constantly walk through use cases. As our understanding deepened, we began to identify places where the new tool would strengthen existing processes and replace legacy tools. I gathered these use cases and began refactoring the project plan to be about solving the use cases rather than delivering software components.
I laid out a plan showing month by month which of the old processes and tools we would provide solutions for. We went back to the stakeholders and proposed throwing out the original plan. In the new “replan” we showed them how month by month we would deliver value to the company, improving the existing processes and tools one-by-one along the way. Rather than spend 6 months coding and deliver a monolithic solution at the end of the project, we found a way to gradually improve things, addressing the audit finding little by little over the 6-month time frame. After the first 3 months, the internal audit team stated that the finding had moved from a high-to medium-risk item because of the improvements already delivered. This delighted our sponsors, one of whom went on to say, “This is the first time I’ve seen a project replan that brought the project in early!” In fact, we did not bring the project in early; what we did was bring some of the value in early.
I began reporting status where each milestone was a release of a “new feature deployed and legacy process retired.” I tracked a separate commit date for each “release” and counted it as a commitment made or missed. By having pieces of our software and processes in the hands of the customer early, we’d learned how to make them better as we went, a project quality benefit that wasn’t our prime driver but was a pleasant side effect. Over the next 3 months we completed the remaining components and spent time improving the interfaces that we’d built early on. The net result was highly satisfied customers and stakeholders. In the end, I reported seven legacy processes and tools retired or improved, only one of which missed the committed date. The project was seen as a great success and in my performance evaluation I was able to report that I met customer expectations six out of seven times (86%), which was a much more precise and meaningful metric for 6 months of work than a single “project on schedule” measure at the end. Running multiple large projects this way over the course of the year would enable me to show my value as a project manager, meeting customer expectations far more often than not, even if I were to be on a troubled project that missed its final due date.
Also Read: Agile project management with scrum
Planning a project in this way—breaking the project into phases that deliver value, committing to (baselining) one phase at a time, and adjusting the sequencing of phases to meet business needs—provides an opportunity to gather metrics each time value is delivered, multiple times during the project. This in turn influences how project progress is communicated to stakeholders and ultimately how the success or failure of the project is measured.
At the end of a 2-year-long project the conversation could be:
“The project was able to deliver value to the customer and met expectations 11 out of 12 times, delivering late just once.” (92% on time, 100% on scope, 100% on budget)
Or it could instead be:
“After 2 years, this project was 3 months late but met its full scope and budget commitments” (0% on time, 100% on scope and on budget)
Which project would you rather be remembered for?