Think about 15 years ago when you purchased a new device, or you were starting in on teaching yourself how to use a new software application – think about how long it took you to get up to speed on its different functions and features, how to use them, understanding what situations those features would be most useful in and, overall, how long it took you to become proficient with this new tool. Today, we are learning how to use new tools all the time, with competing applications and devices always jockeying to implement a more efficient function or make a common task easier to complete.
This accelerating rate of change has a direct correlation and impact on how (and why) software is being built. Often, companies find out several months into a development project that they need to make a change to scope in order to stay competitive in a key area. This is the new reality and the ability to effectively incorporate change into your work is no longer an option – it’s required.
As you may know, the Project Management Body of Knowledge, or PMBOK, is a heavily process-based methodology for managing projects. It’s made up of a fairly lengthy series of inputs, tools and techniques, and outputs that are used to keep even large scale, highly complex projects on track from start to finish. Much of the work is done in the first two phases (Initiating and Planning) where a number of documents are built and created that will be utilized as the rather rigid framework for the duration of the project. And for many, they have experienced good results using the PMBOK approach when project requirements and scope were well thought-out and documented in advance, and the way the tool would be used and the value it would produce was well-established and documented. And most importantly, where change to scope is minimal. PMBOK and significant change in a project mix about as well as oil and water, and this is why we’ve seen the rise of agile methods in today’s environment.
However, as we stated earlier and is self-evident by just looking around, the pace of change is still accelerating. Change is the new constant in this world – especially when it comes to anything having to do with technology. So the question may be, is the PMBOK approach (or “Waterfall” to those of you in the business) still a viable approach within technology in today’s economy? There are new methodologies commonly used now that are built around the assumption that significant change will occur during the project, so the approach is designed around anticipating this change and working with it (aka Scrum, Extreme Programming, Lean, etc.) to deliver the project successfully.
However, I propose that learning both PMBOK and Agile approaches are necessary for seeing the full picture, and achieving the best results across a variety of scope and project types. As an example, when you’re learning to play the piano, even though you want to learn the songs you hear on the radio, your teacher will start you with the classics; Beethoven, Bach, Debussy, Joplin, etc. While these styles or methods may not suit your own taste today, learning the methods and lessons from our past gives us amazing perspective and clarity in how and why we operate the way we do in our modern environment. It allows us to be multidimensional, utilizing multiple tools for different situations, and even more “agile” as we encounter various projects.
With that in mind, let’s apply this to project management now:
- Without understanding the importance of driving a strong planning phase (PMBOK), how can you really understand just how critical it is to have thorough, rich conversation with the Product Owner when getting started or during the Sprint Planning (Scrum) session before a new sprint kicks off?
- Without understanding the importance of establishing and documenting a good communication plan (PMBOK), how can you really know why taking the time to define and empower each member of the team on their unique roles and responsibilities is key to success in Scrum?
- Without having realized the value of building out a comprehensive Work Breakdown Structure (PMBOK), how can you understand how crucial it will be to tightly manage the Product Backlog, and to strategically build a series of sprints that will deliver the ultimate value your customer is seeking?
While not all the approaches are the same between the two, much of the core value and best practices from PMBOK are carried into agile approaches, though their implementation may look somewhat different at first glance. The point is, having that historical knowledge from PMBOK and why it has been so valuable can actually make one a far more effective project manager.
So is PMBOK destined for the dustbins of yesteryear? Is the technology industry eventually going to break free from its shadow? I’m not so sure that is going to be the case – nor am I convinced that would be for the best. And for those of you who choose to be a student of both, maybe you’ll find yourself better able to adjust your approach to your next project, depending on the dynamics and factors that are in play.