PM Commentary by Stacy Goff
In the first two parts of this series, we discussed the timing and actions of the first portion of any successful project. We made assertions about a number of useful actions, that some people might find to be overwhelming. Is it really necessary to do “all that stuff?” Could some be skipped? Certainly, you could skip much of that, and “hero” your way through every project. Many organizations still operate that way, even after 25+ years of smarter approaches. Yet, there are exceptions, counterpoints and illustrations of the assertions we made in the first two parts of this subject.
Agile PM is thought to be a “new thing,” and is often proclaimed to be an alternative to BDUF, Big Definition Up Front mentality suggested by the first two articles in this series. Despite the claims of newcomers, Agile PM began, not in the mid-1990s, but in the early 1980s. Of course, we were early advocates of Ken Schwaber’s Scrum in the early 90s, and Kent Beck’s work with Extreme Programming later. But way before those advancements, there were two camps in Information Technology projects that were in favor of leaner PM methods:
- Development-oriented talent, who did not understand the importance of the fuzzy front end of a project, including estimating, funding, staffing, requirements definition and design alternatives. Often, the resistance to these actions was fierce, because the actions obviously didn’t generate code, and thus, only delayed getting to “the good part” of the project. Indeed, many of the “new agile methods” of the early and mid-1990s repeated this theme. I recall heated disagreement about the need to understand the existing situation, the flow of data, and the business processes, because “any adept developer can respond to those discoveries.”
- Many savvy and experienced project managers of the early 1980s resisted using the in-vogue massive methodologies that were designed for 35,000 hour, multi-year projects. Why? These 1970s artifacts would crush the emerging 3,500 hour, done in six months efforts that became the norm in the 1980s. Thus, they intelligently selected the PM actions that did the most good in achieving business results, while imposing the least overhead.
This ability became an essential competence for performing project managers. While not going to such extremes as “the code represents the dynamic requirements and documentation”, they moved away from the process-driven and forms burdened approaches they encountered.
Further, as organizations increasingly recognized that as many as half their people were working on 8-360 hour Small Projects, there was another order-of-magnitude of scaling needed. And as part of their new-found awareness of lean PM and the need for scaling method to project size, they also discovered that the most-important PM skills and competences also totally shifted at repeatable levels of project scale.
Organizations and practitioners realized that several factors should cause competent and performing project teams to scale down or skip the monolithic process-and-forms-driven methods they identified factors to consider to map the rigor needed to the nature of the project:
- Size of the projects. Methodologies selected that are appropriate for the project’s size (and risk).
- Prerequisites in place. One purpose of the list of early-project results in the preceding post is to assure that the prerequisites for success are in place—at the right time to do so. To a great extent, today’s useful and productive Agile PM methods, assume an entire range of prerequisites.
- Those include:
o The right talent is available, ideally, full-time;
o You have continuous access to the right internal Customers;
o Clear business requirements are available, and verified;
o Funding and schedules are flexible, within reason;
o The business case and project priority is clear to all participants;
o Few or no interruptions will deter the team from their project role;
o The team members have the interpersonal skills to work well together, even under pressure;
o Approval of needed changes will trigger changes in funding and timelines, as needed;
o The solution can be incrementally delivered, so useful business benefits appear quickly.
In today’s Agile projects, what would be the consequences if some of those items are missing? It might surprise you, but this list is not from Agile; instead, these were the project ‘success factors’ of the early 1980s. They were the smart practices of competent and performing project managers from the early 1980s, which we integrated into our methods and training. And, this is in all disciplines, not just Information Technology.
One purpose of the first 10% of any project is to establish those prerequisites. That action will help keep any agile project from turning into a fragile one. Of course, some project results, by their nature, cannot really be delivered in an incremental manner. Imagine incremental delivery of a Manned Mars Mission program, for example. At a certain point, we must have all the parts ready for a blast-off, and doing a “house-call” is difficult en-route.
So we assert that even in an Agile project, the extensive list from our Part 2 posting is also a useful checklist for the Agile Team, to understand their Risks, and act to resolve them. We have seen entire organizations that can quickly go through that extensive list from Part 2 in one week or less for major projects, and move on to product deliverables. Your Comments?