Extreme Project Management (XPM) is a methodology used to describe how to deliver projects on time and budget based on the scope. Is the theory behind this concept really new, or just another name for what many project managers already know? Either way, this article points out the true "extremes" of project management, highlights the theory behind XPM, and provides some guidance on when to use the technique.
Project Management Styles
Since this article is about extreme project management, let's first identify the two "extremes" in project management.
The first extreme is the "just do it" approach to project management. There is no real planning, and everyone begins to work on different pieces of the project. There is no overall coordination of the tasks or plan for how the pieces will fit together to accomplish the project objectives. Speaking of the objectives, these were probably not clearly defined or perhaps not defined at all. The obvious problem with this approach is that it doesn’t work and the project will run over-budget, over-schedule, and fail.
The second extreme is "cross every T and dot every I". The planning process is done at such a detailed level that the project never really gets started. Once the scope, plan, and objectives are fully defined and agreed to, the team realizes they used 50% of the time and budget for the project to define the plan. Now the dates and costs on the plan are obsolete and they need to go back and revise the plan again. As you can see, this approach does not work because the planning phase never ends and work never begins.
If these are the extremes, shouldn't there be a "happy medium" approach? This approach would offer the necessary planning and control but also be flexible to accommodate changes. The term used to describe this approach is Extreme Project Management (although I prefer DPM, meaning Deliberate Project Management).
What is Extreme Project Management?
A complete list of all the functionality for a project is defined. The business owners determine what the most important pieces are and what functionality should be delivered first. If a piece of functionality cannot be delivered within a few weeks, a further breakdown of the item is needed.
For example, "input and store the data on screen A" may be more than a few-week deliverable. This task would involve finalizing the graphical user interface (GUI), designing the database structure to hold the data, possibly including calculated values and error handling. All of these pieces do not need to be delivered at the same time.
Segmenting the functionality, the first task may be to deliver the GUI design, then establish the database to hold the data. Additional pieces may also include perform calculations and establish error routines. At the end of the process, the customer has all the functionality they need, but it was delivered to them in pieces.
Delivering the functionality in pieces may also save time. Once the users see the GUI, they may begin defining other information needs or "nice to haves". These functional items should be written down and prioritized by the customer along with all the other functional pieces. This approach allows the team to make adjustments on the fly but not lose control of the overall process, schedule, and positive outcome of the project.
There will be more releases under this approach, but this does not necessarily impact the overall timeframe. As test scripts are written for each discrete piece of functionality, more focused thought will be put into them and should provide an overall improvement in the testing effort. The scripts will be saved and run against all iterations along with new iteration scripts to ensure nothing was broken. When errors do occur, the analysis of what caused the error will be simplified since there are a limited number of changes and additions since the last release.
While work on the current release is underway, the functionality for the next one or two iterations should be very specifically defined. This creates rolling wave iterative cycles that will ultimately meet the project scope and objectives.
When to use Extreme Project Management
As you can see, there are many benefits to Extreme Project Management. However, like most things, you need to use the right tool for the job. Once a project has been defined at a high level and specific business functionality exists along with a well-defined scope and objectives, the XPM approach can be used.
Attempting to use XPM for strategic planning and project prioritization will not work. Since the major premise of XPM is delivering functionality in 2-4 week increments, using the approach for strategic planning or project prioritization will not be effective.
XPM works best for the detailed tactical work necessary to complete a project. The approach can also be used on minimal changes required for system maintenance and other discrete work products. Keep in mind that is approach is defining very specific deliverables to be completed in a 2-4 week timeframe.
Is XPM Really a New Concept?
The PMBOK (Project Management Body of Knowledge) supports XPM through the term "progressive elaboration". Progressive means “proceeding in steps; continuing steadily by increments". Elaboration means "worked out with care and detail; developed thoroughly". The nine PMBOK areas still apply when using XPM, but the cycle time is compressed to a few weeks for each functional component.
Other criteria and considerations for successfully implementing XPM includes, but are not limited to:
Are these concepts really new? Successful projects require the project manager to be the leader and build solid relationships with and between all team members. Corporate culture always plays into what approach will work best for the organization. Defining the scope is critical to any successful project, as well as defining specific, measurable results, quality control, and most important strong and constant communication.
Summary
Given the rapid change in technology and business needs, it is impossible to accurately plan and schedule a multiple-month project up front. Regardless of the total length of the project, delivering functionality every few weeks will help keep the project on track. This approach also helps to keep the customer involved throughout the process since they can see verifiable results every few weeks. XPM allows for changes on the fly, and requires constant communication among all team members. XPM should only be used during the project execution and change control processes and should not be used for overall strategy, vision, or project prioritization.
Lets Hang!