Two Modes Are Better Than One
As I read about current trends of thinking in IT or Project Portfolio Management (PPM) news sources, one of the most popular topics is “bimodal IT,” which is most simply defined as the practice of managing two separate modes of IT delivery within the same organization, portfolio or even project. Typically, one of the modes is focused on stability (think Waterfall), and the other on exploration (think Agile). Another way to think about it is measured and risk-averse versus more rapid and iterative.
The fact of the matter is that even before “bimodal IT” was coined, more progressive IT organizations realized they had to figure out how to effectively deliver both applications that are more predictable and those that have more uncertainty. The bottom line is that any time you are building something new (as opposed to enhancing or fixing a legacy system) there is significant uncertainty, making pure waterfall less than optimal. See the blog I wrote in 2010 on how to blend multiple frameworks on one project (“Waterfall Agility”). I did not know about bimodal IT in 2010, but we were helping clients add value through real life applications of this philosophy.
For a concept that seems so natural, why do organizations struggle to make it work? Similarly, why is there so much controversy about how to implement bimodal? My thought is that like many new things, fear of change is at the core of problem. Application development practitioners fear change from frameworks they know well. Likewise, executives who sponsor IT initiatives fear the loss of transparency into their IT projects in the form of traditional project and portfolio health metrics to which they’ve become accustomed.
In my opinion, everybody should relax. Bimodal will not lead to the end of traditional delivery methods because those still make sense for certain types of applications and projects. It’s about getting multiple delivery / management frameworks to coexist, thereby allowing organizations flexibility to choose the model that best fits the project instead of trying to fit all projects into one framework. Even more powerful is to blend frameworks within a project, which can become a necessity when dealing with two different types of development frameworks and teams that need to come together to deliver business objectives. Kenway recently managed a project that required a mainframe team and a web development team to deliver code changes to meet the objectives of the business. This project was best served by leveraging a mix of traditional and agile structures. Over the years, Kenway has found four key success factors to make bimodal project management a success.
1. Follow traditional frameworks for issue and risk management. While agile practices allow for more collaborative execution, we’ve found traditional issue and risk management processes to be more effective and do not disrupt the benefits of the agile framework.
2. Normalize key project health metrics to provide senior sponsors “apples to apples” transparency in status reporting. Too often it seems as though agile is used as an excuse to provide little or no executive visibility into projects. In reality the challenge is to provide executive level status in a format that is relevant and consumable. When managing a project or portfolio of projects, you can standardize the following metrics across projects regardless of framework.
a. Scheduled Completion Date(s)
b. Percent Complete
c. Scope Changes
d. Actual vs. Estimated Cost
3. Create and maintain a high level project plan to understand dependencies and critical path milestones between the different frameworks. Once this integrated plan is baselined, it is important to clearly articulate the milestone points in the project where the two frameworks must come together and be managed as one. Please note that if this point is at go live, then you haven’t planned well enough! Taking the example above, the web team was free to use agile, while the mainframe team took a more traditional approach. The high level plan tracked the work efforts at the sprint and activity level of detail respectively until system test. The joint team determined up front that since business users had defined more traditional requirements, it made sense to have functional code in place across both frameworks for an end-to-end system test to confirm the business requirements were being met. The project then moved into traditional User Acceptance Testing.
4. Include the right experience and skills in your project management team. While it only makes sense to include all expertise necessary to deliver a bimodal project or program, we see too often organizations trying to manage multiple frameworks with one project manager. While “super PMs” are out there, there are not many of them, not to mention the inherent key person risk results when leveraging one. Yet too many organizations are stuck on the one project / one project manager rut. At Kenway, we solve this problem as we do all resource mix related problems: by providing the right skills in the right volume at the right time for the right duration. In most cases, but especially when dealing with bimodal, utilizing appropriate (not less, not more) capacity from a plurality of resources providing project management services are better than one.
Bimodal IT is a hot topic right now because many organizations are reaping the benefits of agile, which is a good thing! Every IT organization should understand applications that would benefit from agile and have a plan to move in that direction. But not EVERY application or project has to move to agile, and bimodal IT allows these systems to peacefully coexist in one organization or even within one project. If you’d like to discuss bimodal IT or share other experiences, let us know at firstname.lastname@example.org.