Replacing the Iron Triangle of Project Management?
Last Updated on Thursday, 15 November 2012 01:04 Written by Mike Cottmeyer Thursday, 28 January 2010 03:36
Last year sometime, I heard Jim Highsmith do a talk on replacing the traditional project management iron triangle with a new ‘agile triangle’ that is based not on time, cost, and scope… but instead, based on value, quality, and constraints (time, cost, and scope). This is a concept Jim introduced in the latest release of his book Agile Project Management: Creating Innovative Products. Something in the idea has been bugging me a little, so when I read Isreal Gat’s post this morning, discussing ways to use Jim’s agile triangle, it got me thinking.
I’m curious if the agile triangle follows this same pattern. If I increase value, does quality have to go up or down? Do the constraints have to change? What about if I change quality? Does value go up? Do I have to change the constraints? What about the constraints? If I tweak the constraints, does that always impact value or quality? There are some guesses that we can make, but the agile triangle doesn’t give us any guidance. The relationships between the variables are less precise, and therefore I think using the triangle metaphor is less powerful.
My Life is a Project?
Last Updated on Thursday, 15 November 2012 01:04 Written by Mike Cottmeyer Wednesday, 23 December 2009 04:23
When I’m giving talks or teaching a class, I often talk about how I think about nearly everything in my life as a project. So much so that my wife sometimes complains that she is not a project that I have to manage! She get’s tired of talking about risk mitigation strategies and desired outcomes. She isn’t particularly interested in understanding our assumptions or constraints and really does not like being called a primary stakeholder.
In all seriousness… I don’t quite take it that far… but I do tend to see things through a ‘project’ lens.
Earlier this morning I came across a great post by Scott Berkund titled ‘Everything is a Project‘. I liked the post so much (for obvious reasons) that I sent it out as an ‘Interesting Post…’ over Twitter. Several folks re-tweeted my tweet and a few folks commented. One of the comments came from Bob Marshall, aka @flowchainsensei. Here is what Bob had to say:
@flowchainsensei Way too many things are projects – especially projects. Projects are dysfunctional, wasteful and anti-flow. Let’s put an end!
And my response…
@ mcottmeyer I think that the project metaphor can be useful when we don’t have level investment across product lines.
Clearly this was way too deep a topic to explain in 140 characters, so I wanted to share my thoughts around projects and where I think they are useful… and where I think the concept is overused.
First… the simple definition of a project goes something like this… ‘a project is a temporary endeavor, with a defined beginning and end, that is created to achieve some particular goal or desired outcome’. I’m pretty sure that definition came from the PMBOK, but I lifted the language from Wikipedia. Pretty basic and seems to make sense, but does it fit the way that our organization really does work?
Here is another example where I think projects are misused. If I am a small company that is developing a single product, and my primary mission in life is to keep that product updated with new features and defect free… is the work I am doing project work? I may be inclined to have a “UI redesign project” or a “Revise the login and authentication project”. Are either of these projects? They could be, but because of the nature of my environment, what we are really doing is ongoing product development.
But… what if I am building a custom solution that will be handed over to the customer at the end of the contract period. I may provide ongoing support, I may not. In that kind of environment, it might make sense to have a project manager and a charter… a formal risk mitigation plan and at least a high level schedule… even in an agile environment. I have touch points with my primary stakeholders (no, not my wife) and they have certain expectations about how their money is going to be spent. This sounds like it could be a good place to have a project.
Let’s consider another example… What if my product company grows up and now we are supporting 20 different products and have 40 to 50 teams. Your product sets are not all the same level of maturity. Some are established and don’t need incremental investment.. some are less mature and require new features to be added to meet market demand. The point here is that the investment in each product is not level and the business is making strategic decisions about where it will spend its money to get the greatest return. I think that projects make sense here too. We are making an increment of investment, over a pre-defined period of time, to get some desirable outcome.
So… do I think that projects are overused? Yes. Am I willing to say that all projects are bad and that the entire metaphor is outdated and always inappropriate? No. Like most everything we talk about here… you have to understand your context and not apply concepts blindly where they don’t make sense. If your work is more operational and ongoing… that is not the sweet spot for project management. If your work is well defined and discrete, and it lends itself to the problem that project management is designed to address… I think the concept is valuable.
It is not a one size fits all world. I look forward to the conversation.
Project Management 2.0
Last Updated on Friday, 16 November 2012 12:50 Written by Mike Cottmeyer Friday, 18 December 2009 06:01
I put Project Management 2.0 as the title just to give Glen Alleman a moment of pause Actually, Andrew Filev has posted 33 of his favorite thought-provoking blogs on Innovation, Project Management, and Web 2.0. Since Andrew was kind enough to include Leading Agile… and he is asking his readers to vote for their favorite… I thought I would include a link to his post here.
Managing Expectations about Uncertainty
Last Updated on Friday, 16 November 2012 12:50 Written by Mike Cottmeyer Thursday, 10 September 2009 10:59
The PMI crowd generally believes that a Project Manager is supposed to manage uncertainty out of the project. The Agile crowd tends to believe that uncertainty and change is something that should be embraced. Rather than managing OUT uncertainty, the agilist chooses to manage FOR uncertainty.
This difference fundamentally influences how we go about the business of planning projects… the artifacts we create… and how we interact with and manage our teams. The reality is that both worldviews have a place depending upon your context and problem domain. It’s up to us [as Project Managers] to recognize the nature of the projects we are working on and choose the strategy most likely yield a desireable outcome… for both our project stakeholders and our external customers.
We cannot check our brains at the door and blindly follow ANY methodology. It’s up to us to assess our situation and choose an approach that is suitable for the task at hand.Learn More
Why Project Managers Like Documentation
Last Updated on Friday, 16 November 2012 12:52 Written by Mike Cottmeyer Monday, 1 December 2008 12:39
Reposted from Artem’s Agile Software Development Blog
Most software project managers have very little power in an organization. They are on the hook for delivery, but have very little control over the actual resources required to get the job done. Project managers have to broker agreements, hold people accountable, and get people to do things that they are not otherwise incented to do.
Fixed Constraints and Up Front Design
Requirements documents are created early, and often with little input from the delivery team. Budgets are set and timelines negotiated, prior to the project team even being engaged.
In other words… project managers are in a pretty bad spot. They are trying to manage in a situation where the triple constraints are all set for them, they have little direct control over resources, and the resources they have are matrixed across several projects with competing priorities and differing agendas.
Project Managers Want to Succeed
Project managers are often very driven people. They are detailed oriented and focused. Believe it or not, project managers don’t want to fail. Project managers are people that are committed to being successful… they want to deliver and do a good job.
So… what can a project manager do to ensure success? Focus on paperwork and process.
Paperwork and Process Defines Success
Because project managers are in an impossible situation, they retreat into self-preservation mode. They focus on comprehensive documentation and sign-off to hold people accountable. They put process and documentation over working software because the constraints of the organization ensured failure from the very beginning.
Over time, people get used to operating in this manner. Project managers get promoted and run PMOs. They run development organizations. They become a part of the business. The challenge is that they carry these self-preservation attitudes with them as they move up the ranks.
We have ended up with a bunch of leaders that think this is the way software gets created. They think that paperwork and process is the way software gets delivered to market. The thinking is so pervasive, no one even questions how we got here.
Changing Behavior Will Take Time
If we want to change this behavior and begin to tear down these walls, we need to encourage transparency and create an environment of trust. Project managers need to be able to bring the difficult issues to the business and be assured that the business will not punish them for their integrity.
Companies need to create a culture where assumptions get validated, and when they are not valid, the plan changes. We need to create a culture where risk is managed, but when it is realized, we accept responsibility for our mitigation strategies. We can talk about change management, but we have to understand that change is not free.
I understand it is difficult to run an uncertain business. We can’t wish that uncertainty away and we need structures and frameworks to help deal with it. Agile project management is just such a framework. Agile help us embrace uncertainty and deal with it.
Holding Project Managers Accountable
Hold project managers accountable for effectively managing assumptions and risk, good decision making, and proper escalation to the right people. Hold them accountable for how well they communicate and keep the business informed. Reward them for coming up with creative proposals and implementing effective strategies.
Unless we want mountains of documentation no one will ever read, let’s stop holding project managers accountable for plans that should never have been laid in the first place.
Photo Credit: www.polaricecapz.com/