With the increasing interest in Agile techniques such as Scrum and XP, I often come across clients and project managers assuming that these approaches alone are sufficient to ensure the success of their projects. In actuality, the Agile Principles are really a value system that help contribute to effective behaviors on a project. None of the agile techniques recommend dispensing with the well defined practices that govern effective project implementations such as risk, scope and change management (amongst others). In fact most of the Agile techniques found in current literature are intended to work within existing frameworks and metamodels, without which your projects won’t succeed.
When I develop project plans and teach project management approaches, I frequently turn to the Metamodel offered by the Unified Process. What I like specifically about the Unified Process is that it breaks a project into four phases (Inception, Elaboration, Construction and Transition) that have clear entry and exit criteria that are easy to manage against. In addition the phases are well defined and relatively intuitive to most people (Inception involves scoping and structuring the project, Elaboration focuses on de-risking the project and developing an Architecture, Construction emphasizes the rapid development phsae of the project and Transition focuses on readying the application for deployment).
The UP also contains a number of useful ‘disciplines’ which reflect major workstreams in a project lifecycle. Business Modeling, Requirements, Analysis and Design, Implementation, Test and Deployment ebb and flow across the project lifecycle while Project Management, Configuration/Change Management and the Environment disciplines are focused on supporting the lifecycle in its entirety (these latter are found in the IBM version of the Unified Process called the Rational Unified Process.
The popularity of the Unified Process is reflected in its evolution into a number of forms including the Agile Unified Process, Enterprise Unified Process and even the Oracle Unified Process. IBM recently released an open source version called OpenUP which is based on its popular Eclipse Process Framework.
Over time I’ve come across a number of agile/lean techniques that support the disciplines I mentioned above and enhance these disciplines to make them more effective. Over the next few postings I’ll offer a walk through on a discipline by discipline basis on each of these techniques.
Discipline by Discipline
Requirements and Analysis
Creating a project status report is as much art as it is science. A good status report contains critical project information that senior leaders and stakeholders can review to understand overall project health and progress. The status report should also not take hours of time for a project manager to complete. I’ve used many status reports over the years. I developed this template based on not only classic PMP status indicators (like schedule, budget, scope) but financial metrics and project reference information (such as project code). All of the core project status information is included ‘above the fold’ for easy reference when the document is opened. However, from experience attaching a document to an email reduces the likelihood of it getting read by about 50%. To address this I copy and paste the dashboard information of the status report and paste it in the body of the email. That way even a busy executive can quickly scan key project vitals through the preview feature of their standard mail program.
The Weighted Criteria Assessment Matrix is a tool designed to aid decision making involving a large number of criteria or decision points. This tool is primarily used for technology decisions but can easily be modified for any multi-criteria decision. As the name suggests, these criteria are ‘weighted’ based on their importance to the decision. The goal is to provide an objective assessment of a decision (which can be a product selection or an architecture decision). Any number of products or decisions can be compared simply by “copy and pasting” one of the existing columns into a new column. This template includes an instructions tab which provides more details.
The Iteration Route Map is a tool that identifies what functionality will be delivered in each iteration of a project. As the name suggests it acts as a map that project stakeholders can reference in order to anticipate how the application will develop throughout its lifecycle. The Iteration Route Map is primarily used by the architect and development team to manage analysis and design and implementation activities throughout the project but every team member and stakeholder will find value in reviewing it once completed. The template comes with instructions and examples.
One reason so many software development projects fail is a poor testing framework to ensure what is developed will actually work in production. Developing a comprehensive test plan for a software development projects requires a specialized skill set but as a project manager you need to be able to ask the right questions before signing off. This article is part of a series that provides ten tough questions every project manager should ask when reviewing the testing components of a project plan.