~ By Kathleen Hass
Traditional project management involves very disciplined and deliberate planning and control methods. With this approach, distinct project life cycle phases are easily recognisable. Tasks are completed one after another in an orderly sequence, requiring a significant part of the project to be planned up front. For example, in a construction project, the team needs to determine requirements, design and plan for the entire building, and not just incremental components, in order to understand the full scope of the effort.
Traditional project management assumes that events affecting the project are predictable and that tools and activities are well understood. In addition, with traditional project management, once a phase is complete, it is assumed that it will not be revisited. The strengths of this approach are that it lays out the steps for development and stresses the importance of requirements. The limitations are that projects rarely follow the sequential flow, and clients usually find it difficult to completely state all requirements early in the project. This model is often viewed as a waterfall.
Today, business processes are more complex and interconnected than ever before. Additionally, they reject traditional organisational structures and involve complex communities comprised of alliances with strategic suppliers, outsourcing vendors, networks of customers, partnerships and even competitors. Through these alliances, organisations are able to address the pressures of unprecedented change, global competition, time-to-market compression, rapidly changing technologies and increasing complexity at every turn. Because of this multifaceted nature of businesses, projects that implement new business systems are also more complex.
For years, economists have been warning that success in a global marketplace is contingent upon the capability to produce small batches of tailored products on a tight schedule to meet growing demands in emerging markets. Looking at results the past project performance record is troubling:
Improving these performance records is a goal for any organisation. However, if traditional project management is somewhat ineffective, it's time to examine other methods of designing and delivering projects.
For projects involving a significant software component, traditional project management can be somewhat ineffective since the requirements are elusive, volatile and subject to change. An alternative approach, Agile Project Management (APM), is emerging in the industry. APM is a highly iterative and incremental process, where developers and project stakeholders actively work together to understand the domain, identify what needs to be built, and prioritise functionality.
Agile methods are used when these conditions are present: project value is clear; the customer actively participates throughout the project; the customer, designers, and developers are co-located; incremental feature-driven development is possible; and visual documentation (cards on the wall vs. formal documentation) is acceptable. See figure 3
The Agile approach consists of many rapid iterative planning and development cycles, allowing a project team to constantly evaluate the evolving product and obtain immediate feedback from users or stakeholders. The team learns and improves the product, as well as their working methods, from each successive cycle. After a streamlined planning, requirements definition and solution design phase is completed to get the project underway, iterations of more detailed planning, requirements, design, build and test take place in waves. This approach allows for immediate modifications of the product as requirements come into view. APM requires a dedicated full-time project team that includes a customer or end user, where team members work from the same location.
APM development is conducted collaboratively, with a small co-located team. This core team usually consists of two developers who write code in pairs (for quality control), the customer/end-user, IT architect(s), a business analyst and a project manager. The work is accomplished through a series of sessions where the team writes code, then tests working modules of the system and repeats the process. There is minimal documentation as the team relies almost exclusively on informal internal communication.
Again, this differs from the traditional approach where a considerable amount of time is invested in planning and a significant amount of requirements documentation is produced. The Agile team identifies and prioritises the features based on business value, and after high-risk components of the system are produced, works on the highest value features first. This approach works if the solution can be delivered incrementally to the customer. If this is not possible, features still can be built incrementally and then integrated into the first release of the system.
There are several key elements that provide the basis for APM. These techniques can also be used in traditional software development methods to improve project performance.
The principles of APM are timeless and links closely to leadership. It addresses a lot of the steps that facilitate leadership much more than traditional management,says Sanjiv Augustine, Managing Director of the Lean-Agile Consulting Practice at CC Pace Systems in Fairfax, VA. The project manager works with the client management, the IT management and the key stakeholders to ensure they know the project's status. Additionally, the project manager removes any barriers hindering the core Agile teams.
The traditional project management approach, Augustine reports,
is a linear approach where you try to get it all done at one time. You do a lot of very detailed planning at once up-front and then deliver it in what's known as the Big Bang. That industrial age thinking has spilled over from software development to other projects as well. This is the heart of the difference between Agile and traditional project management.
The Big Bang now comes from the greater flexibility and collaboration APM provides. "Just enough" planning is done up-front. As each increment of the system is built, the team gathers input and learns from customer feedback. Since the customer sees and/or experiences a working prototype, he or she is better able to refine or redefine requirements and describe to the team what the organisation really needs. The Agile method embraces changes that add value, and reduces the cost of change through iterative development. Making changes to a small module is very cost-effective, compared to designing and developing a huge system and then trying to make changes to it.
At its heart, project management, traditional or Agile, has very similar principles. It's about doing a good job for the customer. It's about leading a team. It's about delivering measurable business results, says Augustine. Many of these principles or practices can be implemented into most team-structured environments. Yet, some project management professionals may discard the principles of Agile management if they are unable to adopt all of the components and practices. This is a mistake. For example, what happens if they cannot get the user to sit full-time with the team in the workroom? It doesn't mean they can't incorporate some of the other pieces of Agile management such as visual control and feature-driven development. Besides, even if a user cannot be involved on a full-time basis, most users are willing to participate on the team, especially during the testing and feature prioritisation. The rest of the time, the business analyst can represent the user while the full-time core team continues to work together.
Incorporating Agile management techniques into projects fosters a focus on the benefits of each feature. In traditional project management, the teams strive to finish the project on time and under budget and often lose sight of the overall benefits the entire effort is intended to bring the organisation. It's important to remember the strategy the project is expected to advance as well as the total cost of ownership and not just the project costs. In this way, the benefits of the project will be obvious, whether the team is constructing a building or developing a new business solution.
Kathleen Hass is the Project Management and Business Analysis Practice Leader for Management Concepts. Ms. Hass is a prominent presenter at industry conferences, author and lecturer in the project management and business analysis disciplines. Her expertise includes IT strategic planning, implementing PMOs and portfolio management, leading technology and software-intensive projects, executive coaching, building and leading strategic project teams, and managing large complex programs. Ms. Hass has over 25 years experience providing professional consulting services to Federal agencies, the intelligent community, and various Fortune 500 companies. Ms. Hass can be reached at firstname.lastname@example.org