Agile Project Management
Agile Project Management focuses on more on massaging projects to fruition rather than managing them to completion. The agile approach maximizes value received by having the customer continuously prioritize work being undertaken in terms of value to the organization. The attempt is to focus on establishing a baseline that is built up in an organic way, so that at each turn the system both operates and offers value to the organization.
Agile Portfolio Management would be to use the same mechanism but abstracted up a level. Projects themselves would be evaluated by examining the value they add to the organizational bottom line. Those that contribute more would be undertaken with higher priority. This of course leaves the quandary of how to you determine value at the bottom line for something as intangible as most IT projects.
Using terms like bottom line value brings us back into the realm of theory of constraints with its assertion that Net Profits is equal to Throughput less Operating Expenses. By applying that here, the clearest way to evaluate project priority would be to identify which projects can maximize their value while minimizing their investments.
Agile Portfolio Management would be to use the same mechanism but abstracted up a level. Projects themselves would be evaluated by examining the value they add to the organizational bottom line. Those that contribute more would be undertaken with higher priority. This of course leaves the quandary of how to you determine value at the bottom line for something as intangible as most IT projects.
Using terms like bottom line value brings us back into the realm of theory of constraints with its assertion that Net Profits is equal to Throughput less Operating Expenses. By applying that here, the clearest way to evaluate project priority would be to identify which projects can maximize their value while minimizing their investments.
posted by mgelbwaks at 9:42 AM
1 Comments:
This is from Jerry Odenwelder through email:
I read your post and have a question about thrashing - which is exaggerated at the portfolio level - and maybe it's just where I work and/or where I'm deployed :-)
As a general rule, at the project level if the priorities change from release to release - or iteration to iteration - it's not that big a deal; you delivered value in the last iteration/release and in the next iteration/release you deliver different value.
However at the portfolio level, and above, this change in priorities has a greater impact. Additionally, if this direction change occurs from quarter to quarter - or year to year - the objectives of projects that make-up the portfolio could start to thrash and ultimately little or no value is achieved. Obviously this assumes that to achieve a large project smaller projects are created and each provided value in smaller iterations than the larger project (so a 1 year project would contain multiple 3 month projects that add value and they would contain 1 month projects that add value, etc).
The only example I can think of is really a bad example but I'll use it for now hoping that you have a better example. Suppose an organization wants to achieve CMMI level 4. They start an effort of smaller projects that help them achieve this goal but the goal cannot be reached for 5 years. Before the 5 year mark, the world changes and someone realizes that they can gain more value from being SOx compliance. Based on this the direction of the organization, and all portfolios, needs to change to maximize value and minimize investment. So CMMI is downgraded and the SOx initiative starts. Then, as a result of some other world change, the value of CMMI becomes higher. This cycle goes on and on, and gets more complicated when the Gelbwaks-Odenwelder bill is passed.
Like I stated maybe that's a bad example, but you can see this organizational thrashing. I know we've felt this at the project levels in Borland - we need offline; no we can get more value from Word integration; no we get the most value from a Eclipse plug-in, etc - and I expect they are the same at higher levels only amplified (just look at how little progress Borland's made in ALM over the past 4 years).
Maybe this problem is caused by the fact that time elapses between establishing a time goal and it's fulfillment and the world changes in that time. Each of these changes impact the goal - sometimes drawing you towards the goal and sometime moving you away from the goal (this makes me think of another example around leapfrogging the competition). The solution here is to minimize this time, however with some goals the time is just large and there is nothing you can do about this.
How do you minimize or control this trashing?
Any insight from Segue?
My apologies if I'm rambling - I hope I accurately expressed my issue.
Thanks for your input.
/jerry
Post a Comment
<< Home