I saw a blog post this morning that I have to respond to because it is so misguided and misleading. The blog post is entitled “Project Managers – Is Agility Just a Toolbox That You Can Simply Pick and Choose From?“.
The essence of this post is that there are project managers who have acquired “a PMI-ACP certification and little else in real-world Agile experience” and see “agile and traditional project management as a toolbox” that they can just mix-and-match together. There is an implication that I and others who have advocated blending the two approaches together as necessary to fit a given situation are in that category; however, that indicates a fundamental misunderstanding.
Learning to blend Agile principles and practices in the right proportions with traditional project management principles and practices to fit a given situation can be a difficult thing to do and it’s not just a matter of picking-and-choosing different “tools from different toolkits” and blindly mixing them together – it takes a lot more skill than that. It is more a matter of developing the right mindset to rise above the level of seeing different approaches as a collection of mechanical practices and seeing the principles behind the approaches at a deeper level as complementary rather than competitive. An additional obstacle is that there are many stereotypes and misconceptions on both sides of the fence that you have to get past to develop an objective point of view in order to see this in that kind of perspective.
In my book. I use the analogy of a project manager as a “cook” versus a “chef” (Bob Wysocki who originally created that analogy but I’ve used it a number of times). A “cook” knows how to prepare a limited number of recipes and does it “by the book” without much improvisation. A “chef” knows how to prepare a much broader range of recipes with more exotic ingredients and also knows how to prepare his or her own unique recipes to fit a given situation. I think that analogy fits this situation very well – in order to learn how to blend Agile and traditional plan-driven principles and practices, we need more people who are “chef’s” rather than “cook’s”. Being a good cook is not a matter of randomly picking out spices from different spice racks and mixing them together – it takes a lot more skill than that and learning how to blend Agile and traditional plan-driven principles and practices is the same way.
I’ve developed a free online training course called “Learn the Truth About Agile versus Waterfall” that is only 30 minutes long that is designed to help people see “Agile” and “Waterfall” in a fresh, new perspective as complementary to each other rather than competitive – you can check it out here:
I recently wrote an article on a “Business-centric Approach to Agile“. Have you ever thought about how similar an enterprise-level Agile transformation is to “Business Process Reengineering (BPR)”? The similarities are amazing but I suspect that many people don’t think of any relationship between BPR and Agile.
Business Process Reengineering (BPR) was very hot in the 1990’s. One of the catalysts that precipitated the need for BPR was the advent of new Enterprise Resource Planning (ERP) systems. ERP systems enabled many companies to much more completely automate their business processes but it was a gut-wrenching change for many companies because implementing an ERP system in many cases required rethinking their business processes to take a much more cross-functional approach to their business. Another important catalyst was “lean manufacturing” which seeks to eliminate the use of any resource that does not create value for the end consumer. Does that sound like an Agile enterprise-level transformation?
Here’s how Bain and Company defines “Business Process Reengineering”:
“Business Process Reengineering involves the radical redesign of core business processes to achieve dramatic improvements in productivity, cycle times and quality. In Business Process Reengineering, companies start with a blank sheet of paper and rethink existing processes to deliver more value to the customer. They typically adopt a new value system that places increased emphasis on customer needs. Companies reduce organizational layers and eliminate unproductive activities in two key areas. First, they redesign functional organizations into cross-functional teams. Second, they use technology to improve data dissemination and decision making”
Source: Bain & Company: Insights – Management Tools, Business Process Reengineering
Let’s take this definition one step at a time:
- The first statement is “Business Process Reengineering involves the radical redesign of core business processes to achieve dramatic improvements in productivity, cycle times and quality” – there’s no question in my mind that that statement could apply to an Agile transformation, but do companies really realize that and do it that way?
- The next statement is “In Business Process Reengineering, companies start with a blank sheet of paper and rethink existing processes to deliver more value to the customer.” There’s also a good fit with that statement. You may not start with a “blank sheet of paper” and throw out all your existing management processes, but it is definitely important to rethink many existing stereotypes and misconceptions that exist about both Agile and traditional management approaches before you launch into an Agile transformation.
- The statement that “They typically adopt a new value system that places increased emphasis on customer needs” is very relevant to an Agile transformation but is probably not given the attention that it deserves. When a company implements an Agile transformation, it is often done from a limited development perspective focused on how it improves the development process but that needs to be done in a larger context of how it improves the customer value that the company delivers to its customers.
- The last statement is absolutely very relevant to an Agile transformation: “Companies reduce organizational layers and eliminate unproductive activities in two key areas. First, they redesign functional organizations into cross-functional teams. Second, they use technology to improve data dissemination and decision making”
I’m not defending BPR, there were definitely some problems in the way it was implemented, but there’s a lot we can learn from it (both good and bad). If more companies realized how similar to Business Process Reengineering is to an Agile transformation and treated it that way, the probability of success would probably be significantly higher. It expands your thinking to see an Agile transformation in an overall business context rather than a very limited development-centric perspective.
I’ve developed a new online training course called “Making Agile Work for Your Business” that is designed to help companies see this perspective and to take a business-centric approach to successfully integrate an Agile development approach into their business.
I recently participated in a forum on PMI-ACP® when someone asked “What’s next after PMI-ACP®?”. I thought it was an interesting discussion and is worth elaborating on further. I believe that the individual who asked the question was wondering what new certifications PMI is going to come out with for people who have a PMI-ACP certificattion and are interested in continuing to advance their knowledge and career in that direction.
It’s a perfectly understandable question but, unfortunately, the answer may not be what you might want to hear. It raises a much larger question of what’s an “Agile Project Manager”? and what’s the career path for someone who has a project management background and is interested in developing into an Agile Project Management role? Many project managers have been thinking that PMI-ACP® would open up a new career path into Agile and it’s just a matter of getting another certification to move further, but I don’t believe that to be the case for a couple of reasons:
- The role of an “Agile Project Manager” is not well-defined and is also somewhat controversial at this point in time. it’s very difficult to certify someone to have those skills when they are not well defined and contentious.
- The PMI-ACP® certification tests general knowledge about Agile and Lean and is not designed around a specific role like the CSM (Certified Scrum Master) certification is.
- Agile is much more heavily based on “tacit” knowledge versus “explicit” knowledge. It requires a lot more judgment and it’s not something that you can easily codify in a document like PMBOK that you can test and certify people against. For that reason, even if the idea of an “Agile Project Manager” was more well-understood, it still might be very difficult to develop a certification exam to test that someone really has the skills to fill that role.
The PMI-ACP certification is a great step in the right direction by PMI to try to close the gap between traditional plan-driven project management and Agile but it just doesn’t go far enough and it also leaves open some very large questions that any project manager who is interested in Agile would naturally want to have answered about what their career path is. Agile is rapidly changing the whole “ball game” for project managers and it’s very understandable that project managers have questions about what their career direction is.
The truth is that any project manager who has a PMI-ACP® certification who wants to further develop into an Agile Project Management role has to be somewhat of a “pioneer” to lead the way for other project managers at this point in time. It can be a difficult transformation, it’s certainly not a matter of just getting another certification, and the ultimate role you wind up in may be very different from a conventional notion of what “project management” is. You have to be a real self-starter to start out on that journey but I think it’s a survival issue for many people in the project management profession to move in that direction.
I am passionate about helping project managers move in this direction and I’ve developed some training courses to help. Check out this video for a summary of the training courses I’ve developed and how I think they help people make this transformation:
What’s Next Beyond PMI-ACP®?
This is a difficult problem but I believe that this is critical to the future of the project management profession and I’m determined to help project managers make this transformation. You can find more detailed information on any of my training courses here:
Agile Project Management Training Course Details
A lot of people may think that it is inconsistent to impose constraints that the project needs to be completed within a certain expected cost and schedule on an Agile project. It is difficult, but it definitely can be done – one of the areas where that becomes essential is Agile contracts. For example, I once managed a large federal government project that had all the typical government contracting requirements for cost and schedule milestones; but, at the same time, the government customer wanted some level of flexibility to work out detailed requirements as the project progresses.
Does that sound inconsistent? It might be depending on the relationship you have with the customer. Obviously, this will only work if there is a spirit of trust and partnership with the customer to collaboratively agree to work out any tradeoffs between the scope of the requirements and the cost and schedule of the contract as it progresses. If there is more of a typical “arms-length” contracting relationship or some kind of adversarial relationship, it’s not going to work at all.
Doing this requires a hybrid Agile approach that blends an Agile development approach with a plan-driven “shell”. The plan-driven shell provides some level of predictability and control over the overall scope, cost, and schedule of the project while the Agile development approach operates within that shell to provide some level of flexibility and adaptivity in the detailed requirements. That approach is described in more detail in my article on the “Managed Agile Development Framework“.
Jeff Sutherland has created a very nice model for this called “Money for Nothing, Change for Free”. Jeff’s approach is based on two primary clauses in an Agile contract:
- “Change for Free”
The “Change for Free” clause is based on the idea that the customer can make any change they want provided that the total contract work is not changed. This allows new features to be added provided that lower priority items are removed from the project. I have documented a case study in my book on how General Dynamics, UK successfully used this approach on a large government contract in the UK.
- “Money for Nothing”
The “Money for Nothing” clause is interesting. It recognizes the fact that in many projects, the customer always asks for everything that they could possibly need but if you prioritize those items and deliver the highest priority items first, at some point you will reach a point of diminishing returns where the cost of developing incremental features exceeds the value that those features provide. This clause allows the customer to cancel the contract at that point and save 80% of the cost that would have been spent to complete the remaining items; however the contractor receives a fee of 20% of the cost for early cancellation which makes it a win/win for both the customer and the supplier.
This concept is not limited to fixed-price contracts – that’s only the extreme case. It can be applied to almost any Agile project where there is a need for some level of predictability and control over the costs and schedule of the project. Very few people get a “blank check” to do an Agile project without any expectations of what will be delivered and what the estimated cost and schedule of the project are likely to be.