Success, Part 3: 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.
Success, Part 3, With Agile PM
Agile PM is thought to be a “new thing,” often proclaimed as an alternative to BDUF, Big Definition Up Front mentality. Despite the claims of newcomers, Agile PM began, not in the mid-1990s, but in the early 1980s. We were early advocates of Ken Schwaber’s Scrum in the early 90s, and Kent Beck’s work with Extreme Programming. But way before those advancements, there were groups 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. They disdained early estimating, funding and staffing actions, requirements definition and design alternatives. Often, their resistance to these actions was fierce, because they obviously didn’t generate code. Thus, delayed getting to the good part of the project. Indeed, many of the “new agile methods” of the mid-1990s repeated this theme. I recall heated disagreements about understanding the existing situation, the flow of data, and business processes. Why? Because “any adept developer can respond to those discoveries.”
- Savvy project managers of the early 1980s resisted using the massive methodologies that were huge, 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. They intelligently selected the PM actions that did the most good in achieving business results, while imposing the least overhead.
This became an essential competence for performing project managers. They moved away from the process-driven and forms burdened approaches they encountered.Further, organizations recognized that as many as half their people were working on 8-360 hour Small Projects. They became aware of the need to scale method to project size. And, they discovered that the most-important PM skills and competences totally shift at repeatable levels of project scale.
Success, Part 3 Realizations
Organizations realized that several factors should cause competent and performing project teams to re-think their processes. That they should scale down or skip the monolithic process-and-forms-driven methods of the past. Instead, they needed to identify the factors that map the rigor needed to the nature of the project:
- Size of the projects. Selected methodologies that are appropriate for the project’s size (and risk).
- Prerequisites in place. One purpose of a list of early-project results is to assure that the prerequisites for success are in place, At the right time for early decision-making. Most of today’s useful and productive Agile PM methods assume that an entire range of prerequisites is in place.
- 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, whether on index cards or in some other format;
o Funding and schedules are flexible, within reason;
o The business case and project priority is clear to all participants;
o Little 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 those items are missing? These were the smart practices of competent and performing project managers from the early 1980s through the present. And, this is in all disciplines, not just Information Technology.
Consequences
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?