Agile Portfolio Management
Much of what occurs during Iteration -1 is the preproject aspects of portfolio management. When a project is first proposed, an initial investment will be made in defining it, identifying a viable strategy for the project, and assessing its feasibility. This effort can and should be as agile as you can possibly make it—you should collaborate with stakeholders who are knowledgeable enough and motivated enough to consider this potential project and invest in just enough effort to decide whether to consider funding it further.
To define the project further you will want to look at the bigger business picture and focus on market concerns. This includes exploring how the new functionality will improve your organization's presence in the market, how it will impact profitability, and how it will impact the people within your organization. This exploration effort should be brief—not all projects will make the initial cut so you only want to invest enough effort at this point to get a good "gut feel" for the business potential.
Although traditional methodologies will recommend developing a vision document, I prefer Outside-In Development's (www.outside-in-thinking.com) focus on identifying the potential stakeholders and their goals, key information to help identify the scope of the effort. At this point in time, strategic business ideas start to turn into tactical decisions, something that will continue into Iteration 0 and beyond. Yes, there's a fuzzy line between Iteration -1 and Iteration 0 efforts—your organization must implement these activities in a manner that fits the context of your own unique situation.
There are several issues to consider when identifying a potential strategy for the project. For example, do you build a new system or buy an existing package and modify it? If you decide to build, do you do so onshore or offshore? Will the work be solely done by your own development team, by a team from a system integrator (SI), or in partnership with the SI? What development paradigm—traditional/waterfall, iterative, or agile—will you follow? Will the team be collocated, near-located within the same geographic region, or far-located around the world? As you can see, there are many combinations of strategies available to you, and at this point you may only be able to narrow the range of the possibilities but be forced to leave the final decision to the project team in future iterations.
During Iteration -1 you will want to do just enough feasibility analysis to determine if it makes sense to invest in the potential project. Depending on the situation, you may choose to invest very little effort in considering feasibility; for many systems, just considering these issues for a few minutes is sufficient, whereas for some systems you may choose to invest days, if not weeks, exploring feasibility. Many organizations choose to do just a little bit of feasibility analysis during Iteration -1, and then if they decide to fund the project, they will invest more effort during Iteration 0.
In my experience, you need to consider four issues when exploring feasibility:
- First is economic feasibility, asking whether it makes sense from a business point of view to go ahead with this project.
- Second is technical feasibility: Are you capable of either building or buying this system? An important consideration of technical feasibility is whether the right people will be available for the project.
- Third is operational feasibility, which considers whether you can run the system effectively once it's in place. Just because you're able to build/buy it doesn't mean that you're capable of keeping it going.
- Fourth, and often trickiest, is political feasibility, which asks whether your organization could tolerate the system and the changes that it will engender.
Your feasibility analysis efforts should also produce a list of potential risks and criteria against which to make go/no-go decisions at key milestone points during your project. The various flavors of the Unified Process (UP)—such as OpenUP, Rational Unified Process (RUP), and Agile UP—have specific milestone reviews that are critical decision points that enable effective portfolio management. Dr. Dobb's 2007 Project Success Survey ("Defining Success," www.ddj.com/architect/202800777) found that agile teams reported a success rate of 72 percent (traditional projects had a success rate of 63 percent), implying that almost 30 percent of agile projects are considered failures. Disciplined agilists know that you also need to question the feasibility of the project throughout the lifecycle: Just because you're delivering working software on a regular basis doesn't mean that it's a good idea to do so.
