Using Development Methodologies
In this chapter, we explore various development methodologies used on projects either alone or in conjunction with a bigger project framework. Most project work can be a chaotic activity, often characterized by the phrase "fighting fires." The project is often started without much of an underlying plan, and the designs are often changed because of technology or error. Sometimes the project is simply cobbled together from multiple quick-paced decisions. This can be effective if the project is small, but as the project grows to be a medium- or super-sized project, it becomes increasingly difficult to add features to the system. The project manager's coordination skills are tested to the fullest extent as the project gets larger. Furthermore, mistakes become increasingly prevalent and difficult to fix (i.e., change control, issue logs). For example, building a space vessel begins with a blueprint based on numerous aeronautical and mathematical calculations, including material specifications, variables, and tolerances. Any change to this blueprint, which must be followed at all times, can kill the project because changes are costly and schedules can be horribly affected. The tools and materials that were manufactured specifically for the space vessel project are very expensive and should not change during the construction phase. On such a project, everything needs to be predictable.
Alternatively, when we look at developing software, we see something very different. We obviously try to build new software solutions—usually with new technologies—therefore, the associated risks are very high. In comparison to building space vessels, developing software is not the same. One is predictable and the other is not. In this chapter, we look at predictable methodologies, then at nonpredictable ones.
How Many Development Methodologies are There?
There are no one-size-fits-all development methodologies. Some companies have their own unique customized methodology for developing products or services; others simply use standard commercial off-the-shelf methodologies. With the incorrect methodology, discovering, designing, building, testing, and deploying projects can be chaotic. At least 20 different methodologies are competing to be the best methodology, and this list of methodologies keeps on growing (see Figure 4.1).
Figure 4.1: Assessing project development methodologies.
The project methodology that is chosen represents merely the framework for the real work to be done and indicates where creativity is needed. Many times, project managers simply select the available methodology and continue to develop their projects with that same methodology. When unpredictable results occur on a project, they raise issues and risks and try to manage reactively. Project managers often lack the controls to measure and respond to the unpredictable. Therefore, they must first determine that the methodology is the correct one.
Many project managers find it difficult to give up control as provided in traditional development. There is no guarantee that the team will deliver if you just follow a chosen methodology. Clients seldom complete requirement specifications because their requirements are constantly changing. The most logical solution is to simply evolve the product as the client's needs change along the project development process. This shows the need for a methodology more flexible than a formal waterfall approach. In fact, the trend is shifting to the more iterative or incremental style of methodologies.
Most project developments are wrongly approached with the assumption that the methodology used is well understood, and the project can be easily planned and estimated. When a project begins to fail, the development process is immediately provided with more resources and attention to get it back on track. Thus, cost and schedule overruns start occurring. These step-by-step approaches do not work because they do not cope with human and technical unpredictability. Rigid processes are often too constraining and fall short of delivering a project to operations or production.
Influence of New Product Development
In today's progressive marketplace, every moment counts. Companies developing new products, whether new bridge construction or a wireless mobile device, usually do so concurrently with existing product developments, often competing for similar resources and delivery dates. These projects must be developed in a synchronized approach with some differentiator toward the development of new stellar products. Hence, a competitive project methodology is needed that can show value and reflect the corporate strategy goals and objectives. The project team, armed with the right tools, techniques, and methodology, can keep the client involved and improve the bottom line. The methodology can be adjusted to fit the solution. The Standish Group's landmark 2000 report, "Chaos in the New Millennium," reports that outright project failures declined from 40 percent to 23 percent during the past five years but challenged projects swelled from 33 percent to 49 percent in the same period. Reasons listed included cost overruns and projects with lower functionality than promised. The correct choice of methodology plays an important part in elevating the rate of failures (see Figure 4.2).
Figure 4.2: New product development process.
Requirements for Selecting a Methodology
Table 4.1 illustrates essential decisions a project manager must make when selecting a methodology:
Budget. Budgets play a big role in any project, and the type of methodology to be used is key. For example, you have been given a mandate to develop a product within eight months. Your sponsor says, "Money is no problem; we need this product by the end of the year." If you select a heavy methodology, you may not achieve your goal because you will see the results only near the end of the project. (Earned value could possibly help, too.) A light, agile methodology may be the more appropriate choice because many of the lightweight methodologies are done in iterations and budgeted accordingly. If the project appears to be failing, funding is discontinued; if the iteration proves successful, funding for the next release is approved and work continues.
Team size. Methodologies are directly proportional to the team size—use light methodologies for smaller teams and heavy methodologies for larger teams. Projects with teams of 100 members geographically dispersed throughout the globe will not work using a small, lightweight methodology. The lines of communication grow more complex with the increase in team size, necessitating a more disciplined, coordinated model. For example, the Boston Big Dig project, the largest underground artery roadwork project in U.S. history—estimated at $14.5 billion for 7.5 miles of highway—requires thousands of workers across many vendors and employment agencies. A lightweight methodology is not suited to such a project.
Technology used. The technology used on a project affects the direction and type of methodology selected. Unfamiliar technology slows progress. On many projects today, simulation and testing of new technologies is actually considered a phase of the methodology.
Tools and techniques. Some project methodologies require more tools and techniques than others—for example, databases, visual modeling tools, and project management tools; some require hardly anything. If a project manager must manage multiple design changes, he or she will need a configuration management tool and technique.
Project criticality. Any critical project with a "must-deliver" target date needs to have the correct choice of methodology. The project might require additional resources to finish by the required date. If the methodology is too small, the project manager loses control; too large and formal, he or she slows the project down. A project manager's experience and skills will help in choosing the best approach.
Existing processes. In any company, the maturity and ease of use of existing project processes largely influence the methodology. Some company processes may be totally unreliable and ad hoc, slowing down completion of tasks. For example, you follow the standard internal purchasing process, which has a lead time of two months to receive goods. This process requires intervention or change.
Table 4.1: Requirements for selecting a methodology Requirement
Rationale
Budget
Methodologies require money and effects schedule.
Team size
Number of staff to be managed is required.
Project criticality
The urgency of the project decides the methodology.
Technology used
Hardware such as computer servers, composite materials, or electronics may be needed.
Documentation
The methodology needs documentation.
Training
Effective training to key support staff and project managers is required.
Best practices/lessons learned
Past lessons learned and good practices should be available.
Tools and techniques
Tools and techniques must be available.
Examination of existing processes
The maturity of existing processes will influence the pace at which a project will progress.
Software
Methodologies require software as part of their design.
No two methodologies are ever quite the same. At last count, my research on this topic found 45 different methodologies. If you don't have any methodologies in place in your company, on your next project, begin documenting issues and steps. Each major event (e.g., design) symbolizes either an end to a phase or the beginning of the next phase. All phases have unique activities and deliverables from previous activities. Before moving to the next phase, make sure all the activities and deliverables are completed. If you don't, expect to have more problems than usual.
Understanding Light and Heavy Methodologies
The choice between using a light or heavy methodology determines the success of the project.
Light Methodologies
Ever-increasing technological complexities, project delays, and changing client requirements brought about a small revolution in the world of development methodologies. A totally new breed of methodology—which is agile, adaptive, and involves the client every part of the way—is starting to emerge. Many of the heavyweight methodologists were resistant to the introduction of these "lightweight" or "agile methodologies" (Fowler 2001). These methodologies use an informal communication style. Unlike heavyweight methodologies, lightweight projects have only a few rules, practices, and documents. Projects are designed and built on face-to-face discussions, meetings, and the flow of information to the clients. The immediate difference of using light methodologies is that they are much less document-oriented, usually emphasizing a smaller amount of documentation for the project. For example, they are somewhat code-oriented: The team considers the source code as the project documentation. Advantages of a lightweight methodology include:
It works well with change.
It is people-oriented rather than process-oriented. It works with people rather than against them.
The methodology is complemented by the use of dynamic checklists.
If a client constantly introduces frequent changes to the design to see what the solution will look like—possibly to see immediate results or functionality of the product—a light methodology may be the suitable route to follow. Although you might set some limits to prevent too many changes, in today's ever-changing technological environment, clients might prefer that the project proceed in smaller iterations. The great thing about light methodologies is that they are learning methodologies. After each build or iteration, the team learns to correct issues on the project and improvement cycles form throughout the project. Additionally, with light methodologies, the project teams are smaller and rely on working more closely, fostering knowledge sharing, and having almost instantaneous feedback. The project manager does not need to develop heavy project documentation, but should instead focus on the absolute necessary documentation (i.e., project schedule).
Heavy Methodologies
The traditional project methodologies (i.e., SDLC approach) are considered bureaucratic or "predictive" in nature and have resulted in many unsuccessful projects. These heavy methodologies are becoming less popular. These methodologies are so laborious that the whole pace of design, development, and deployment actually slows down—and nothing gets done. Project managers tend to predict every project milestone because they want to foresee every technical detail (i.e., software code or engineering detail). This leads managers to start demanding many types of specifications, plans, reports, checkpoints, and schedules. Heavy methodologies attempt to plan a large part of a project in great detail over a long span of time. This works well until things start changing, and project managers inherently try to resist change.
If the project manager does not obtain a complete list of user requirements from clients for the heavyweight project, it's very likely that the heavy methodology will not work effectively because the project will be racked with change, slippages, and rework on the project documentation. A heavyweight methodology works on the assumption that the more rules and coordination there are, the better the project result will be. A complex project requires sufficient documentation just to jog the memory of the many team members on the project. However, excess methodology is very costly and inept—there are more updates to reports, plans, and schedules. Alternatively, there are times when a heavyweight methodology may be appropriate for super projects where it is necessary to gain stricter control and coordination between phases, and to improve the lines of communication between team members.
Any project with a team larger than 10 to 20 people who work in multiple locations may be a good candidate for a heavyweight methodology. Many companies are simply rushing to try to come up with the biggest and best methodology—including the most templates. Many, expecting miraculous results, become disappointed after a few months of actual project work. Because technologies are becoming more complex and integrated—facing many design and development problems—heavyweight methodologies can sometimes be the best choice, especially when multiple teams are working at different locations and when tighter control and formalization of key parts of the project is necessary.
Demystifying Iterative Development
Project managers or developers often confuse the meaning or use of the terms incremental, evolutionary, or iterative. Incremental, iterative, and evolutionary development are in fact the same thing. They execute all project phases (i.e., design, build) more than once. Whereas linear development (i.e., SDLC) is not. On any project, team members must understand the difference in these terms because they can define the future course of the methodology being selected or proposed on the next project. Iterative development adds agility to your project. For example, if you start a project and the executive sponsor informs you to follow an iterative approach, would you know what the sponsor meant? The following analogy best describes the differences in terminology:
Iterative. When building a house, the first iteration of the house is torn down, redesigned, and the second iteration is built from scratch. The emphasis is on re-doing the project. In the construction industry, this can be impractical and expensive; but in the information technology industry, this approach is common.
Incremental. When building a house, we start off with a basic design, and then incrementally add more rooms to the house. The emphasis is on adding to the project or expanding it. In addition, incremental models are best used to do a phased delivery to clients (e.g., release 1, release 2). This approach is more orientated to formal projects such as construction projects; information technology projects also use this approach as a dynamic way of delivering projects to clients.
The main difference between the iterative and incremental approaches is that you can still live with the incrementally built house, but the iterative house that has been torn down needs rebuilding.
Benefits of Iterative Development
The iterative development methodology provides the following benefits:
It encourages user feedback, which promotes obtaining real user requirements.
The system grows by adding new functions to each iteration.
Developers or planners start focusing on the biggest issues or risks facing the project.
Any misconceptions about design and requirements are identified upfront.
Everyone on the project has an accurate snapshot of the project status as it progresses.
Continual testing is carried out during the project.
The project workload is spread more evenly over the life cycle.
It allows for lessons learned on prior versions to be used in future releases.
The project or development manager divides the development/ design schedule into a few iterations (e.g., iterations 1, 2, 3, 4, 5, and 6). Each iteration is one to four weeks. The iterative approach now forms the basis for everything forward. Iterative approaches need to be managed slightly different from a normal project, as each iteration is built on its specific set of user requirements at that time. As iteration 1 is completed and reviewed with the project team and client, another iteration is planned wherein additional requirements and functionality are built into subsequent iterations. Each iteration concentrates on capturing the client's most pressing tasks. Instead of creating a detailed schedule, iterative methodology project planning should be more dynamic—each iteration is planned as it comes along, with smaller planning windows.
The Agile Methodologies
Project or development managers are still facing controversy between the agile and heavyweight methodologies. Currently, many companies favor the agile methodologies. Agile methodologies present new, nontraditional ways of building complex products and systems. Projects that use agile methodologies are now starting to report improved time line and cost savings, compared to those in the heavyweight family. Additionally, project teams are hailing the agile family of methodologies as remarkable because, at last, a series of methodologies contributes directly to the business. Many managers (i.e., functional, project, and development) tend to stick with the heavyweight methodology because they want to predict the entire project until the last man-hour, whereas the project teams (i.e., developers, coders, analysts) tend to stick with dynamic shorter cycles. Industries that use agile methodologies include financial, IT, telecom, utilities, and many more service industries. Furthermore, this trend is starting to emerge worldwide. The following are the most commonly used agile methodologies:
Extreme Programming (XP).
Scrum.
Crystal methodology.
Dynamic Systems Development Methodology (DSDM).
Rapid Application Development (RAD).
Adaptive software development.
Lean development.
Feature-driven development.
Agile methodologies better suit small projects where smaller project teams are involved. With larger team size and the complexity and duration of the project, the choice of a heavyweight methodology is purely from a command and control perspective. Many smaller companies do not use heavyweight methodologies and prefer the more agile approach to building solutions.
Extreme Programming (XP) Methodology
XP, one of the new promising breeds of lightweight methodologies, is the brainchild of Kent Beck. XP is one of the agile processes. It has received so much attention in recent years that some of the global project organizations are reviewing it for inclusion in their methodology portfolios. XP has few rules and a modest number of best practices, which are all relatively easy to use. It is based on iterations that embody several practices (like RUP), such as small releases, simple design, testing, and continuous integration. XP also promotes several effective techniques for the appropriate projects and circumstances; however, there are hidden assumptions, activities, and roles. XP teams use a simple form of planning and tracking to decide what should be done next and to predict when the project will be finished. XP embraces four core values that its project teams should follow: (1) communication, (2) feedback, (3) simplicity, and (4) courage.
The focus is on business value, where the team produces the software in a series of small, fully integrated releases that pass all the tests the client has defined. An XP project defines an integrated set of practices, which requires the full-time, on-site engagement, for such a project to work successfully. XP concentrates on construction of code—programming to meet a business need. How that business need occurs—and how it is modeled, captured, or reasoned—is not XP's primary concern. The XP phases are for planning purposes but the focus is on actually building the code. There is little emphasis on project documentation—XP is a clean and focused environment, which allows developers both creativity and freedom during development. The focus of XP is to reduce development costs. Although XP is worthy of consideration as a development methodology, it should not be used on large projects.
XP is a more constrained process that needs additions to make it fit a complete development project. For a small project team working in a relatively high-trust environment where the user is an integral part of the team, XP can work extremely well. Some of the most noteworthy XP practices are:
Refactoring. Restructure the system continually, without changing its behavior, to make it simpler or add flexibility. Determine if this is a good practice for the team. What is simple to one may be complex to another.
Testing. Developers continually write tests to go along with their code. The tests reflect the stories. XP urges you to write tests first, which is an excellent practice because it forces you to deeply understand the stories and then to ask more questions when necessary. Whether before or after code, you have to write them. Add them to your test suite and make sure to run them every time the code changes.
Pair programming. This technique ensures room for two developers to work effectively at a single workstation. This results in better code in less time, because developers can identify errors and possible faults in the software code (Strengthening the Case 2000).
Use CRC (class, responsibility, and collaboration) cards. This advocates that spending time to capture and maintain design documents is fundamental to a project's success. XP projects typically require a few hours to sketch the design or use CRC cards. The cards are used to teach users of XP the principles of object-orientated design.
XP can be used in conjunction with other development frameworks. XP has been successfully used with Rational Corporation's RUP. This combination has been called the dX process and is also RUP-compliant (Martin, nd).
The Scrum Methodology
In the agile community is a light methodology developed by Jeff Sutherland. The name Scrum comes from the game of rugby, played by two teams of 15 players with an oval ball. The ball is carried in the hand and may be passed backwards or laterally across the pitch or kicked in any direction. The opposing players attempt to halt the ball carrier by tackling him or her with their arms. Points are scored by:
Touching the ball down over the opponent's goal line (a try, worth 5 points).
Kicking the ball above the crossbar and between the uprights of a large H-shaped set of posts. This may be done either from a place kick following a rule infringement (a penalty goal) or a kick from the hand, provided the ball strikes the ground before being kicked (a drop goal). Both types are worth 3 points.
A conversion, which is attempted after a try has been scored and is similar to a penalty goal except worth only 2 points.
The purpose of the scrum is to restart play quickly, safely, and fairly after a minor infringement or stoppage. From a methodology perspective, Scrum refers to the mechanism used in rugby for getting an out-of-play ball back into play. Scrum is a lightweight, agile methodology focusing on software development. Scrum's two pillars are team empowerment and adaptability:
Team empowerment. When teams are given work to do, they are responsible for figuring out how to do it. The team does the best it can during each increment. While a team works, its only interaction with management is to tell management what is getting in the way and needs to be removed to improve productivity.
Adaptability. Scrum uses "punctuated equilibrium." The team maintains equilibrium during each increment, insulated from outside disturbance. Increments are punctuated every 30 days so that the team and management can evaluate what should be done during the next increment; this decision is based on what the team has accomplished and what the environment dictates is the next most important thing to do.
Scrum's ultimate goal is to deliver as much quality software as possible within a series (three to eight) of short time boxes (fixed-time intervals) called sprints that typically end every 30 days. Each stage in the development cycle (requirements, analysis, design, evolution, and delivery) is now mapped to this sprint(s). The traditional development stages are retained for convenience, primarily for tracking milestones. For example, the requirements stage may use one sprint including the delivery of a prototype. The analysis and design stages may take one sprint each while the evolution stage may take anywhere from three to five sprints. Defined and repeatable processes work only for tackling defined and repeatable problems with defined people in defined environments.
Before any sprint is started, you define the required functionality for that specific sprint and then allow the project team to develop and deliver it. At the end of every 30 days, the project manager inspects the results, assesses changes in the business environment, and empirically determines what to do next. The goal is to stabilize the requirements during the sprint. Each sprint operates on a number of work items called a backlog. As a rule, no more items are externally added into the backlog within a sprint. Internal items resulting from the original preallocated backlog can be added. The goal of a sprint is to complete as much quality software as possible but, typically in practice, less is delivered.
The project manager or executive does not leave the sprint after completion; he or she remains engaged throughout until all the sprints are finalized. The project team holds daily project meetings—called a Scrum—in which the team quickly runs through the activities for the following day. The following items typically arise from the scrum meetings:
Potential management blockages and problem areas.
Action items for management.
Overall status of completed items to date for the sprint cycle.
Each sprint takes a preallocated amount of work from the backlog. The team commits to it. As a rule, nothing is added externally during a sprint. External additions are made to the global backlog. Blocks resulting from the sprint can also be added to the backlog. A sprint ends with a demonstration of the new functionality. Scrum meetings typically take place at the same time and place every day; therefore, they serve to build a strong culture. As such, Scrum meetings are rituals that enhance the socialization of status, issues, and plans for the team. The scrum master leads the meetings and logs all the tasks from every member of the team into a global project backlog. Scrum meetings allow the development team to "socialize the team members' knowledge" and have a deep cultural transcendence. At the end of each sprint, there is a demonstration to:
Show the client what's going on.
Give the developer a sense of accomplishment.
Integrate and test a reasonable portion of the system being built.
Engage the team.
Ensure real progress—reduction of backlog, not just the generation of more documents.
After gathering and reprioritizing leftover and new tasks, a new backlog is formed and a new sprint starts. In contrast, Scrum allows us to build softer software, so there is no need to write full requirements up front. We should recognize that it is impossible to have full requirements specified upfront or to freeze the context and environment. Requirements are written in a context. Our system transforms that context. New problems arise in the system and the new context (see Figure 4.3).
Figure 4.3: Scrum methodology. Source: SCRUM, Adaptive Development Methodology, SCRUM © 2002. Used with permission of the Agile Community.
Scrum is a knowledge-creating process with a high level of information sharing during the whole cycle and work progress. The keys to Scrum are deciding the completion date for production or release, prioritizing functionality, identifying available resources, and making major decisions about architecture. Compared to more traditional methodologies, the planning phase is kept short because we know that events require changes to initial plans and methods. Scrum uses an empirical approach to development where interaction with the environment is not only allowed but also encouraged, thereby changing the scope. Table 4.2 provides a summary of the Scrum methodology.
Table 4.2: Scrum demystified Agile, lightweight process to manage and control development work.
A wrapper for existing engineering practices.
A team-based approach to iteratively, incrementally develop systems and products when requirements are rapidly changing.
A process that controls the chaos of conflicting interests and needs.
A way to improve communications and maximize cooperation.
A way to maximize productivity.
Scalable from single projects to entire organizations.
A way to detect and cause the removal of anything that gets in the way of developing and delivering products.
Project management for a Scrum methodology involves a much greater focus on iteration and release management, error and fault resolution, and coaching the team to the next project release. Compared to traditional project management, we see that its sole focus is primarily on producing PERT charts, Network diagrams, status reports, and deliverables. The most immediate benefits of Scrum are shown in Table 4.3.
Table 4.3: Scrum benefits Increases user involvement in the development process.
Allows users to change and create requirements as the project progresses.
Ensures that the most important user functionality is built in first.
Always focuses on only the most important functionality.
Achieves new working functionality every 30 days.
Allows the user to choose the "build" or release at any time.
Eliminates the need for projects to be funded more than 30 days in advance.
Identifies something that can be done to improve productivity every single day.
Maximizes the ROI from the project.
Ensures that the team focuses on building only the functionality the user wants, eliminating additional functionality or cost.
Scrum is, therefore, based on empirical controls through inspection and adaptation. These controls are implemented through five basic practices:
Iterations. All work is done in short iterations, usually lasting 30 days. Inspections occur at the end of each iteration.
Increments. An increment of working functionality is produced at each iteration. At the end of each iteration, this increment is inspected.
Emergence. Complex systems emerge unpredictably across time. Their end state can be anticipated but not predicted. It is useless to try to predict their end states, and any such predictions can be misleading. Scrum deemphasizes traditional definitions of the requirements, architecture, and design of the system. These factors are allowed to emerge across time and have successfully done so on thousands of projects.
Self-organization. There are many unpredictable factors in IT development, ranging from technology to personnel. Given this unpredictability, it is important that management and teams are provided with the authority to plan and organize the work as they proceed, using their creativity and intellect to deal with the unexpected. They rely on their experience. They may also use any of the documented, defined development approaches (i.e., use case capturing, object modeling techniques) that they think will benefit the project.
Collaboration. The practice and working environments of agile methodologies work only if everyone collaborates freely and openly with one another. Techniques used here are (1) open working environments and (2) paired programming practices.
Crystal Methodologies
The Crystal methodology is a family of methodologies, which are all lightweight in nature and are segmented, as the name implies, into various color bands a crystal would emit (i.e., crystal clear, yellow, orange, maroon, blue, and violet). All Crystal methodologies are founded on a common value, "very strong on communication, they are human-centric, light on work products and are self-adapting" (Cockburn 2000). Methodology elements can be reduced to the extent that running software is delivered more frequently and interpersonal communication channels are richer. The human-centric approach really focuses on enhancing the work of the people involved on the project. Each member of the Crystal family or methodology addresses different project needs. The focuses of Crystal methodology are to (1) capture those components that make projects successful and (2) provide the project team with sufficient leverage and freedom to perform its work in a fun and creative manner. Additionally, smaller project teams develop better results because the communication is improved largely through close personal interaction and feedback between users, and the team is encouraged. Crystal does not encourage vast amounts of project documentation. Crystal captures the lessons learned from previous development projects, including the latest briefings on human thinking and communication, which is then reapplied to the development environment. The founder of the Crystal methodologies, Cockburn, states:
... Software development is a cooperative game, in which the participants help each other in reaching the end of the game—the delivery of software.... (p. 1)
When the project team starts developing the software, the team members immediately embark on describing their own development vocabulary in a manner that each project member understands. Two main principles of Crystal are:
Put people in the same location for improved development and creativity.
Encourage face-to-face communications.
Dynamic Systems Development Methodology (DSDM)
The DSDM, developed in the United Kingdom, is based on Rapid Application Development (RAD) that uses prototyping reiteration to deliver projects. This model has several aspects that differ from most common models. The difference is that time and resources are fixed and functionality of the deliverable is variable. In other models, the functionality (or product) is fixed, and resources and time are, to a certain extent, flexible.
Businesses today focus on finding the right solutions quickly. DSDM provides a project framework to make this objective achievable. DSDM's goal is speed—but not at the expense of quality. DSDM is independent, ensuring that it is adaptable to meet the needs of any organization. The simplicity, practicality, and flexibility of the approach are suitable for vendors, SMEs, consultants, and so on, making DSDM relevant across a variety of industries.
During the functional model iteration, first-pass descriptions of the new or changed processes are produced for refinement. A pilot project is developed during the design and build iteration. Throughout the development, feedback is used to evaluate and refine the processes so that they can be rolled out to the wider development population with confidence that they will achieve the benefits expected of them.
Implementation of processes involves significant communication and training of the project staff. Because communication is important throughout the development of improved processes and their final delivery, a communication strategy is added to the usual DSDM product set.
The structure of process improvement teams is described based on the DSDM roles and responsibilities. As always, the visionary role is an important one in keeping the focus of the work aligned to the needs of the organization.
Rapid Applications Development (RAD) Methodology
Sometimes users just want to see a product they can understand and not have to wait for the development to get off the build line. Traditional software development methodologies usually follow a sequence of steps with formal sign-offs normally at the end of each project phase. This sequence might be:
User requirements are gathered.
Specifications and the design are formulated.
Development begins and the project is completed.
Testing commences.
This process can be time consuming, but RAD shortens the approach.
But what happens if you discover during the development phase that the technology doesn't work? This has immense repercussions for the entire linear approach, and such a methodology could very well cause the project to fail. The time elapsed between the design and development could run into many months or man-hours. Clients are then often unwilling to take such a loss unless it is part of their key business strategy. Project managers need to employ a far more dynamic approach or project methodology for technologies that are untested or fall into a high-risk category. The RAD methodology may be the most suitable to realize immediate benefits.
Compared with many traditional methodologies, RAD compresses the analysis, design, development, and test phases into a dynamic series of short iterative development cycles. RAD uses shorter project phases, which means that benefits are realized much more quickly. With RAD, each iterative development cycle delivers a functional version of the proposed solution. The approach is almost cyclic in nature. However, many organizations don't have the time to spend lengthy periods on development; they want to see immediate results. By following a RAD methodology, clients are able to use a "building block approach" to see the results. Using RAD, results are almost immediate and the product starts becoming tangible. The developers have the advantage of building on their solution and gradually improving it until it reflects what the client requires. Some characteristics of the RAD methodology are:
Development teams are much smaller than normal.
The development team is integrated (i.e., analysts, developers, testers) and dedicated to the project.
The development phases are shorter, cyclical, and extremely dynamic.
Each release of a RAD version includes actual functionality the client needs.
Releases do not represent entire prototypes; rather, they are usable working systems.
Tasks and activities are performed concurrently rather than sequentially.
RAD makes use of changing technologies and quick decisions.
The entire approach is based on incremental changes, ultimately ending in a quality product.
The project team understands that frequent changes are part of the job.
See Figure 4.4 and Table 4.4 for examples of the RAD methodology.
Table 4.4: RAD methodology Category
Example
Data warehousing
SAP solution
Customer relationship management
Sales force automation (SFA) solution
Legacy applications conversion
Conversion of old mainframe systems to newer platforms
E-commerce applications
Web site development
Figure 4.4: RAD methodology.
Throughout a RAD methodology, it is important for the project manager to understand that a process needs to be followed. Key steps that need to be emphasized are:
Analysis. On RAD projects, it is crucial to interview all the various management staff in the client's organization (i.e., sales, marketing, legal, procurement, billing) for their requirements and objectives. These managers may see higher value in certain areas, and this needs to be captured in the user requirements statement (URS). (An electronic copy of the URS template is provided on the accompanying CD.)
Business model. When the analysis is completed, the task of putting together a business model is of the utmost importance. Here the project team relies on the analysts to formulate and create various options based on the client's intended strategy. This may include the types of reports needed, financial data, and even the workflow for the solution. (An electronic copy of this business case template is provided on the CD.)
Integration. Integration of RAD solutions into existing platforms and legacy systems is challenging; therefore, the RAD project team needs to work closely with the client's technical team to capture any business rules or integration issues that would contribute toward a successful integration of the new solution. The well-known software vendors have, to a great extent, already addressed integration into their software. However, if the required solution cannot integrate with certain systems, some customization and development may be needed. This is where the true nature of RAD reveals itself. It goes through various iterations and is repeated until the solution can integrate into the client's organization.
Documentation update. Because of the iterative nature of RAD, it is wise to maintain and update all project documentation on a regular basis as the versions are changed and new versions are tested. Proper configuration management of not only the project documentation, but also the source code and database instances, will keep the project under control.
RAD prototyping can reduce costs. It allows the project manager and the team to identify risks early during the project life cycle. The approach overlaps project phases. However, one of the biggest concerns found with RAD is with quality assurance during the development of the project. Project managers, therefore, must ensure that quality assurance is built into the project.
Thursday, December 20, 2007
Project Management Frameworks
Overview
Sometimes you are faced with a project that could cost a small fortune—from hundreds of thousands of dollars to a few million dollars. As project manager, you are charged with delivering the project within cost, specification, and schedule. This is often the opening line for many project managers today. Without an effective project framework in place, it will not matter what you do—projects will undoubtedly be more complicated and troublesome. In this chapter, I provide a few project methodologies or frameworks used today across industry, as well as the components that make up these project methodologies. Sometimes, one methodology framework is not the most appropriate to use—you may need to adapt to some other methodology.
Vinod Khosla (April 2001) in "GigaTrends," Wired magazine, states: "Most of our predictions are based on very linear thinking. That's why they will most likely be wrong!"
In fact, the very success of the company could depend on the successful outcome of projects, so it becomes essential that you minimize as much risk as possible and approach projects in such a way that it almost guarantees success. But how do we do this? One technique uses a tried and tested project methodology, which covers all possible areas when a project starts. By employing the appropriate methodology, project managers are likely to deliver the solutions their clients want. I introduce and clarify two types of methodologies. Although they go hand-in-hand, there is a difference.
Project management methodologies (this lays the high-level project framework).
Development methodologies (this provides the detail on system design and development).
It is likely that you will encounter a project that consists of both a project methodology and a development methodology. You have the shell—dealing with the project approach, competencies, and so on—and then the content of the shell—which deals with the specific development approach. You can see more about development methodologies in Chapter 4 of this book. We concentrate on purely project methodologies in this chapter.
Some people would like to challenge my contention that many project managers often live a lie, perhaps by force, when it comes to adhering to a methodology. This normally happens when a project manager is assigned a project already half completed; he or she simply follows his or her best guess and proceeds from there—often ignoring key issues and steps that make a truly great project. He or she continues to plan, predict, and deliver as best as possible, working the best way he or she knows. It appears that many project managers do not want to create the wrong perception on their projects. As soon as the project starts, project managers jump in, build the solution one way, and when they encounter trouble, pretend to build it another way, flying by the seat of their pants. The lesson here is that rigid methodologies are often far too constraining and fall short in delivering a project into production. When we review many projects that have failed, we see that overhead is often created to prove that the methodology is on track.
When starting a project, many project managers gather as much documentation pertaining to the project as they can. They start creating elaborate project Gantt schedules, using sophisticated software tools, extending it to Pert charts, critical path networks, believing that by following a few simple techniques and a trick here and there, the project will start magically taking shape. However, being smart in a few project techniques and being flashy are not synonymous with great results. What's forgotten here is adhering to the methodology, as well as to the development model. You don't have to rigidly follow the project process step-by-step; you can tailor the framework at any stage for each project or solution.
Selecting Your Methodology
Every company currently without a project management framework needs to identify, select, tailor, or build one before managing a project. Some structure is necessary. If management wants their company to be successful in a project-based world, they should start moving. They should think about the following objectives before deciding on a project management methodology:
The overall company strategy—how competitive are we as a company?
The size of the project team and/or scope to be managed.
The priority of the project.
How critical the project is to the company.
How flexible the methodology and its components are.
Best Project Methodology Practices
To ensure a project's success throughout the entire methodology, project managers and project office managers should adhere to the following recommended best practices when selecting, building, or tailoring a project management methodology:
Use standard-proven processes and techniques.
Draw on best industry practices and trends.
Use best practices to reduce common pitfalls.
Look at implementation time and cost reduction.
Minimize excess templates and administration.
Consult industry leaders and subject matter experts (SMEs).
Acknowledge the best path for project implementation.
Recognize what should and should not be implemented.
The following summarizes four key principles in methodology design that should be reinforced:
Use larger methodologies for larger teams.
Use denser methodologies for more critical projects.
Weight is costly.
Interactive, face-to-face communication is most effective.
Methodology Utilization
When using any project framework methodology, ensure that it doesn't become bureaucratic and so administrative in detail that it actually stifles any sense of creativity or overrides common sense. For example, you have a project that must be completed within four months. You have to design and deploy a new product. As project manager, you understand that you cannot spend all your time creating elaborate documentation and hold meetings to create new processes. Time is against you; therefore, it would be wise to first adopt the correct methodology. Developing the organization's project management framework is one of the core foundations of any business to ensure project success. This framework should include:
A total project management approach from start to finish.
The key phases that the company would possibly use.
Inclusion of quality gates or checkpoints during each phase.
Necessary review points between each phase.
Preproject and postproject phases (e.g., sales, operations).
Project templates.
Project processes per phase (i.e., change control, risk).
Using a proven project framework based on industry best practices and tailoring that approach to fit your organization's culture and practices are the keys to success. In the following section of this chapter, we review different types of methodology frameworks used by industry today.
Rational Unified Process (RUP) Project Framework
The Rational Unified Process, or more affectionately referred to as RUP, is a customizable project methodology framework aimed primarily at software development. It is a complete software development process framework that comes with several out-of-the-box examples. Processes derived from RUP vary from lightweight—which address the needs of small projects—to more complex heavyweight projects. To date, projects of all sizes have successfully used RUP.
This methodology enhances team productivity and delivers software best practices to the project team through a set of components, which in turn consist of guidelines, templates, and best practices from thousands of development projects. From large-scale enterprise to agile projects, RUP allows organizations to develop projects more rapidly and deliver quality even when using this process. Table 3.1 and Figure 3.2 show key areas that make up RUP.
Table 3.1: The components of the RUP framework 4 phases
8 iterations (minimum)
9 workflows
57 activities
270 activity steps (approximately)
114 artifacts
38 roles (up to 38 people)
Figure 3.2: RUP project management process. Source: Life Cycles of the Rational Unified Process. Reprinted with permission.
RUP is not merely a process. It is valuable because it embodies many of the best project management practices available today, thereby making it a flexible framework to which project managers can apply their solutions. In other words, you could consider RUP to be a road map for project managers, analysts, testers, and so on. This allows resources to use a common project management terminology and a component "kit" on how to manage projects. If you already know project management, RUP merely becomes a checklist. However, if you are new to project management, RUP gives you a nice overview. Companies such as Wells Fargo and Merrill Lynch and numerous others have used RUP successfully (see Figure 3.3).
Figure 3.3: RUP cycle. Source: Life Cycles of the Rational Unified Process. Reprinted with permission.
The preferred approach to using RUP is to first determine what is missing from the organization's project management environment. After this assessment has been completed, decide how much change the organization can handle. For example, if a company's biggest problem is requirements gathering, RUP offers this process. When this company starts using RUP, you can reassess how successful their requirements-gathering process has worked. Over time, a RUP-based project goes through four distinct phases: inception, elaboration, construction, and transition. Each phase contains one or more iterations. In each iteration, efforts are expended in various amounts to each of several disciplines (or workflows) such as requirements, analysis and design, testing, and configuration management. The key advantage of RUP is reduction of risks (see Figure 3.4).
Figure 3.4: RUP life-cycle phases comparison. Source: Life Cycles of the Rational Unified Process. Reprinted with permission.
Virtually any company can use and customize RUP to suit the needs of its projects. This implies that RUP is as heavy or light as the project wants to go. The implementation of RUP could take from a few weeks to a few years, depending on how much process is required. Above all, use common sense when implementing RUP, as no major tools and techniques are needed. In the future, many companies will use RUP as a project management framework, whereby they can "hang" their best practices. RUP also provides information to help in using other Rational tools for better software development, but does not require the Rational toolset for effective application to an organization. It, therefore, allows you to tailor the process if none of the "out-of-the-box" road maps suit your organization or project. RUP emphasizes the adoption of certain best practices of modern software development as a way to reduce the risk inherent in developing new software. These best practices are:
Develop iteratively.
Manage requirements.
Use component-based architectures.
Model visually.
Continuously verify quality.
Control change.
PRINCE2 Project Framework
PRINCE2 is an acronym for Projects in Controlled Environments (second version) and is now the United Kingdom's de facto standard for IT project management. The Central Computing and Telecommunications Agency (CCTA) originally developed this structured project management methodology, which now forms part of the Office of Government Commerce (OCG)—a government agency—for the development and implementation of IT projects. In fact, this methodology is now so popular that many companies hire only PRINCE2-certified project managers. More and more companies are moving toward adopting this as their standard project approach. Companies such as British Rail, Nat West, Hitachi, BT, London Underground, and Royal Mail, among many others, benefit from using PRINCE2. Some of the many features of this methodology are:
A defined project management structure.
Flexible decision-making points.
A system of plans for resources and technical issues.
A set of control procedures.
A focus on products—deliverables to the client.
A focus on project deliverables throughout the project.
This methodology can readily be applied to non-IT projects as well; therefore, even the construction industry can use this methodology. It is a project management methodology specifically designed to be generic and independent of any particular project type and complexity. This makes PRINCE2 methodology even more interesting to consider. It is nonproprietary, easy to use, and, with some basic training, an excellent approach. Similar to the Dynamic Systems Development Methodology (DSDM) described in Chapter 4, its use is dramatically on the increase in both the public and private sectors. A feature in PRINCE2 not seen in other methodologies is the concept of assuring progress from three separate but linked perspectives. Most organizations that adopt PRINCE2 choose it primarily for its wide applicability and use the pieces that actually "work for them."
Figure 3.5 shows that PRINCE2 is a process-orientated approach for project management. Each process has its inputs and outputs with associated project tasks and activities to be carried out. The methodology shows us that a project is decomposed in manageable phases, allowing efficient command and control. For example, look at project planning. This phase is mainly interested in focusing on results rather than planning when the activities will be done. PRINCE2 is largely driven by its business case (see templates), which describes the business justification, rationale, and motivation for the project. The same applies to all phases shown in the figure. Integrating this methodology into a company's existing culture and processes may require the insight and assessment by certified PRINCE2 project managers, who are knowledgeable of this methodology.
Figure 3.5: PRINCE2 life cycle.
On the upper tier of the illustration, note that the project(s) may report to a corporate program management function. Start at "Directing a Project," which runs from the start-up of the project until the close. This process is aimed at the project board, who manages by exception, monitors via reports, and controls through a number of decision points.
PRINCE2 Phases
The key processes of the project board are these four main areas:
Initiating (starting the project on the right foot).
Stage boundaries (commitment of more resources after checking results reached).
Ad hoc direction (monitoring progress, providing advice and guidance, and reacting to exception situations).
Project closure (confirming the project outcome and controlled close).
This process does not cover the day-to-day activities of the project manager. In the middle tier, we find the phases, which are equally important to any project manager wishing to adhere to this methodology. The phases are:
Starting up a project. The first process in PRINCE2 is a preproject process, designed to ensure that the prerequisites for initiating the project are in place. The process expects the existence of a project mandate, which defines in high-level terms the reason for the project and what outcome is sought. Start-up of a project should be very short and should include the following:
Ensuring that the information required for the project team is available.
Designing and appointing the project team.
Creating the initiation stage plan.
Agreeing whether there is sufficient justification to proceed with the project.
Establishing a stable management basis on which to proceed.
Documenting and confirming that an acceptable business case exists for the project.
Ensuring a form and accepted foundation to the project before starting work.
Agreeing to the commitment of resources for the first phase of the project.
Providing the baseline for the decision-making processes required during the project's life.
Ensuring that the investment of time and effort required by the project is made wisely, taking in account the risks to the project.
Managing stage boundaries. This process provides the project board with key decision points on whether to continue with the project. The objectives of this process are to:
Assure the project board that all deliverables planned in the current stage have been completed as defined.
Provide the information needed for the project board to assess the continuing viability of the project.
Provide the project board with information needed to approve the current phase's completion and authorize the start of the next phase.
Record any measurements or lessons that can help later phases of the project(s).
Controlling a stage. This process describes the monitoring and control activities of the project manager involved in ensuring that a phase stays on course and reacts to unexpected events. The process forms the core of the project manager's effort on the project and handles the day-to-day project management tasks and activities. Throughout each phase, there is a cycle consisting of:
Authorizing work to be done.
Gathering progress status on work.
Watching for changes.
Reviewing the situation.
Reporting.
Implementing the necessary corrective action.
Managing product delivery. The aim of this process is to ensure that planned products are created and delivered, by:
Making sure that work on products allocated to the team is effectively authorized and agreed on.
Ensuring that the work conforms to the requirements of interfaces identified in the work package.
Ensuring the work is done.
Assessing work progress and forecasts regularly.
Obtaining approval for the completed products.
Closing a project. The aim of this process is to execute a controlled close to the project. The process covers the project manager's work to wrap up the project either at its end or at premature closure. Most of the work is to prepare the input for the project board so that they may sign off the project. The objectives for this phase are:
Checking the extent to which the objectives set out in the project initiation document have been met.
Confirming the extent of the fulfillment of the project initiation document and the client's satisfaction with the deliverables.
Obtaining formal acceptance of the deliverables.
Ensuring to what extent all expected products have been handed over and accepted by the client.
Confirming that maintenance and operation arrangements are in place (where appropriate).
Making any recommendations for follow-up actions.
Capturing the lessons learned from the project and completing a lessons learned document.
Preparing the end project report.
Notifying the host organization of the intent to disband the project resources.
On the lowest tier, we find the planning process. It is important because it considers key project processes, which are:
Planning an initiation phase.
Planning a project.
Planning a phase.
Producing an exception plan.
Overall, PRINCE2 proves to be a sensible and practical project methodology. The best feature is that no license is required for using this methodology, except one obtaining the required documentation. Additionally, it is not necessary to purchase special project management tools, as PRINCE2 allows use of any project management tool to manage projects. Project managers who are familiar with PRINCE2 are able to:
Establish terms of reference as a prerequisite to the start of the project.
Use a defined structure for delegation, authority, and communication.
Divide the project into manageable stages for more accurate planning.
Ensure resource commitment from management is part of any approval to proceed.
Provide regular but brief management reports.
Keep meetings with management and stakeholders to a minimum but schedule them at vital points in the project.
Required PRINCE2 Artifacts
There are essential artifacts required by a typical PRINCE2 project. First, the business case artifact used by PRINCE2 is a reasoning or justification of the project. After all, as mentioned in Chapter 1, companies must focus on pursuing only those key strategic projects that produce innovative products and services. Together with this, project managers must ensure that all project risks be identified in the business case.
The business case should be routinely updated to reflect any change to the project, should new risks be identified. It is true that much time is spent on the business case, but this ensures proper planning and coordination. Therefore, the business case gives a clear picture of what is to be delivered. At the start of a project, the product specification is drawn up, which reduces the risk of delivering the wrong product. Although the PRINCE2 methodology does not directly deal with social or "soft" management skills, such as negotiations, presentation techniques, coaching, or leadership, it is necessary for a project manager to possess these skills to be successful.
If your company plans to implement PRINCE2, you would most likely start by training your key staff on the best practices and detail on the methodology and then provide overview training to those who would need to be aware of the methodology. Advantages and disadvantages of using PRINCE2 are discussed in the following sections.
Advantages of PRINCE2
The method is independent of the application domain such as IT software development, marketing, building and construction, and change management. Domain-specific methods such as DSDM, product development methods, or domain-specific standards can be applied in the PRINCE2 teams. This way, the method is generically applicable to any project. PRINCE2 provides a layer over the disciplines that are needed in the project because it defines a flexible "project language" that suits multidiscipline project teams. Therefore, the method bridges the gap between IT and business, for instance.
The method is in the public domain, and services (training, consultancy, and tools) can be obtained from several independent suppliers.
The method has active user groups in the United Kingdom and the Netherlands.
The method is applicable to small and large mega-projects.
The method focuses on project results in terms of the standard time, cost, quality, and functionality parameters but also has a strong focus on business case and the benefits the project results deliver.
The method integrates change management that controls the changing environment.
The method uses management by objectives and management by exception approaches.
Disadvantages of PRINCE2
It is a method and not a cure for any project. People who use PRINCE2 should continue to think.
Some people apply and interpret the methodology in a rigid way and do not tailor it to the project at hand. Huge bureaucracies might be constructed if all checklists are used in a paper format and not adapted to the project.
Human factor or soft issues are not within the scope of the methodology and are desperately needed for project success.
System Development Life Cycle (SDLC) Methodology
Many projects follow the classic waterfall approach, and it is fairly straightforward to conceptualize. No rocket science is needed here. You simply have to focus on the logical progression of what needs to happen on the project. The SDLC is in essence a waterfall methodology. Successful companies such as Johnson & Johnson, Novartis, Adventis, American Express, and Nokia use and adhere to an SDLC approach. Table 3.2 describes the basic methodology phases available for a project.
Table 3.2: Simple approach Phases
Phase Description
Critical Plans
Discovery
Researches and refines organizational objectives for the project.
Strategy/roadmap
Design
Provides the design and solution to the organization.
Blueprint design
Construction
Constructs the product against the design blueprint.
Project plan
Implementation
Implements the tested solution into the organization.
Test/deployment
Follow-up
Ensures that solution is rolled out smoothly and irons out issues.
Maintenance
The project manager should pursue the options and choices of which project methodology to use, depending on the engagement. Tables 3.3 and 3.4 reflect similar methodologies available to project managers when working with a client and deciding which approach to adopt.
Table 3.3: Complex approach Phases
Phase Description
Critical Plans
Definition
Identifies the project team and lists assumptions.
Project schedule
Data collection
Collects data for the intended solution.
Analysis forms
Develop model
Develops a conceptual model of the solution.
Specification
Verification and validation
Confirms that solution performs as required and compared to all measurable results.
Validation plan
Optimization
Ensures that the solution meets predefined success criteria.
Optimization plan
Delivery
Delivers the solution to the client.
Deployment plan
Table 3.4: Generic approach Phases
Phase Description
Critical Plans
Needs analysis
Determine exact client requirements.
URS, Business case
Project concept
Establish business objectives and deliverables from the client.
Project definition
Project design
Start designing the solution for the client.
Specifications
Training
Provide training to users in the client organization.
Training plan
Project delivery
Implement the project per the identified project schedule.
Deployment plan
Project support
Address all support-related aspects of the project.
Support plan
For numerous SDLC-type projects today, the trend and style of these methodologies frequently involve completing one phase after the next. Many are monolithic in nature; they are time consuming and some methodologists are calling these formal giants the dinosaurs of project methodologies. SDLC methodologies at least provide a framework for completing projects, but it's not that these methodologies follow the often-quoted maxim "Ye shall release early and release often"; rather, they rely on "Ye shall wait till each phase is complete before releasing resources for the next." In today's complex digital world, where faster is better, project managers struggle to complete projects where complex, unknown technologies are being used. Clients do want to see results much earlier than before. They insist that you follow a project approach, but they want to see results much more quickly and want deliverables to be delivered sooner. My advice is to go through the various approaches mentioned here and select one that is best suited for your needs, and tailor it accordingly. In addition, refer to Chapter 4 of this book to start a journey into methodologies (see Figure 3.6).
Figure 3.6: Complex life-cycle methodology.
Approach
Needs analysis. This phase is used to determine the specific client requirements for the proposed solution. The needs analysis aids in identifying the exact business and functional requirements.
Project concept. The project concept establishes the business objectives and assumptions, risks, and deliverables into a project concept, which is usually documented and presented to the client for acceptance.
Project design. This phase allows the project design or development team to begin creating or formulating the design for the solution.
Project training. The training phase is an important part of this methodology because it includes training as part of the project. It assumes that training for the user is necessary.
Project delivery. The implementation of the project occurs after training has taken place. This phase ensures that the project is delivered at the relevant location(s) within schedule.
Project support. This phase of the project ensures that the necessary support for the solution has been coordinated and managed. Tasks such as support level agreements (SLAs), escalation processes, and contact lists are performed.
Solutions-Based Project Methodology
Solutions methodologies offer consulting companies the opportunity not only a way to work with clients but also a structured manner in which to deliver projects. They form the standard approach to doing the work. As each solution is different from the rest, it becomes important to adhere to a consistent manner in which projects are managed and executed.
Ray Lane of Kleiner Perkins Caufield & Byers states:
E-business is about rebuilding the organization from the ground up. Most companies today are not built to exploit the Internet, their business processes, their methodologies, their hierarchies, the number of people they employ ... all of that is wrong for running an e-business! (p. 1)
There are numerous e-commerce project and development methodologies available today. They vary largely because of their architectures, technology, and target dates. At a minimum, e-solutions methodologies should consist of the following phases.
Objectives.
Strategy.
Design.
Content.
Development.
QA.
Test.
Launch.
Maintenance.
Creating a Basic Methodology
If you are new to methodologies, you should start with a simplistic approach for your project. The first step is to list a few key phases you think suit your type of business. In the following example, we start building a methodology. Assume you have a small project team in your company and that your aim is to avoid any lengthy documentation or additional steps that will impede project delivery. You can always start elaborating as your project starts gaining momentum. For the purpose of the example, I have randomly selected three basic phases of our methodology:
Explore. Here you need to ensure that the focus remains on completing the business requirements for the upcoming solution. This includes obtaining project information, meeting with your client, and creating a list of assumptions and a project brief or business case. You should drill down into some level of analysis and determine what the project scope is or is not.
Develop. During this key step, start creating at least the project plan, together with any technical specifications you need to build your product. This may include case diagrams and flowcharts. Additionally, during this phase, the role of the deployment plan is highlighted.
Execute. During the execution phase, the physical solution is developed and tested to the point where the solution is rolled out to the client.
With the main phases documented, we need to identify the minimum artifacts or project templates needed. Table 3.5 shows that we need at least a business case document during the "explore" phase. After you have the templates defined and in place, assess which processes you need to support this methodology. Assume that your company or project will be purchasing considerable hardware and services from different vendors. In this case, you need to ensure that you have a procurement and financial process in place to make things easier. If these basic processes are not in place, it is likely that you will be spending more time doing administrative work than managing your project.
Table 3.5: Solutions-based models Basic Phases
Phase Description
Basic Artifacts Needed
Explore
Examine the deliverables needed, as well as resources.
Business case
Develop
Develop solution against specification.
Technical specification
Execute
Implement the solution.
Deployment plan
After the processes have been identified and established, run a simulation or demo to see that everything works the way that you designed it to work. Tweak the methodology by either adding or deleting pieces to the methodology. If your company or project is small, you want to be flexible and able to communicate to fellow team members in an efficient manner without any complexity. Many companies make the fatal mistake of having reams of documentation do the communicating between parties instead of face-to-face communications. But our example is fine. We have kept the methodology to a minimum set of templates and processes, and we have our project team sitting together in a comfortable and relaxing work environment.
As our team or project becomes larger, it will require additional coordination and, regrettably, slightly more documentation. In addition, depending on the technology, we want a highly dynamic project environment that can create this solution quickly (e.g., we want to create a national database that collects and interprets intelligence data from multiple government agencies).
Creating Hybrid Methodologies
There are circumstances in which it may be necessary or appropriate to combine two methodologies to create one perfect tailored methodology. Sometimes, it is more feasible to dynamically build a methodology from other methodologies. You may find yourself starting out using a waterfall methodology, then during the life cycle of the project (i.e., development), you realize that using a RAD methodology may be more appropriate. Remember that each methodology offers its own set of strengths and weaknesses from a methodologist's perspective. In the Air Force, to keep mission-critical aircraft serviceable, the "one-from-two" principle is sometimes employed—two unserviceable aircraft are stripped down and critical parts are used to build one fully functional aircraft tailored for a specific use. This is the concept of the hybrid approach.
For any project manager, this option should remain open, but with sudden change comes risk. Points of safe cutover from one approach to the other must be clearly defined, and the project manager should assess the impacts on schedule, cost, and resources. There are issues with the user involvement in the different streams of development, project management issues including possibly different approaches to change requests in the two approaches, and organization management issues. This is permitted, provided the project management framework in the company can support various development methodologies
Sometimes you are faced with a project that could cost a small fortune—from hundreds of thousands of dollars to a few million dollars. As project manager, you are charged with delivering the project within cost, specification, and schedule. This is often the opening line for many project managers today. Without an effective project framework in place, it will not matter what you do—projects will undoubtedly be more complicated and troublesome. In this chapter, I provide a few project methodologies or frameworks used today across industry, as well as the components that make up these project methodologies. Sometimes, one methodology framework is not the most appropriate to use—you may need to adapt to some other methodology.
Vinod Khosla (April 2001) in "GigaTrends," Wired magazine, states: "Most of our predictions are based on very linear thinking. That's why they will most likely be wrong!"
In fact, the very success of the company could depend on the successful outcome of projects, so it becomes essential that you minimize as much risk as possible and approach projects in such a way that it almost guarantees success. But how do we do this? One technique uses a tried and tested project methodology, which covers all possible areas when a project starts. By employing the appropriate methodology, project managers are likely to deliver the solutions their clients want. I introduce and clarify two types of methodologies. Although they go hand-in-hand, there is a difference.
Project management methodologies (this lays the high-level project framework).
Development methodologies (this provides the detail on system design and development).
It is likely that you will encounter a project that consists of both a project methodology and a development methodology. You have the shell—dealing with the project approach, competencies, and so on—and then the content of the shell—which deals with the specific development approach. You can see more about development methodologies in Chapter 4 of this book. We concentrate on purely project methodologies in this chapter.
Some people would like to challenge my contention that many project managers often live a lie, perhaps by force, when it comes to adhering to a methodology. This normally happens when a project manager is assigned a project already half completed; he or she simply follows his or her best guess and proceeds from there—often ignoring key issues and steps that make a truly great project. He or she continues to plan, predict, and deliver as best as possible, working the best way he or she knows. It appears that many project managers do not want to create the wrong perception on their projects. As soon as the project starts, project managers jump in, build the solution one way, and when they encounter trouble, pretend to build it another way, flying by the seat of their pants. The lesson here is that rigid methodologies are often far too constraining and fall short in delivering a project into production. When we review many projects that have failed, we see that overhead is often created to prove that the methodology is on track.
When starting a project, many project managers gather as much documentation pertaining to the project as they can. They start creating elaborate project Gantt schedules, using sophisticated software tools, extending it to Pert charts, critical path networks, believing that by following a few simple techniques and a trick here and there, the project will start magically taking shape. However, being smart in a few project techniques and being flashy are not synonymous with great results. What's forgotten here is adhering to the methodology, as well as to the development model. You don't have to rigidly follow the project process step-by-step; you can tailor the framework at any stage for each project or solution.
Selecting Your Methodology
Every company currently without a project management framework needs to identify, select, tailor, or build one before managing a project. Some structure is necessary. If management wants their company to be successful in a project-based world, they should start moving. They should think about the following objectives before deciding on a project management methodology:
The overall company strategy—how competitive are we as a company?
The size of the project team and/or scope to be managed.
The priority of the project.
How critical the project is to the company.
How flexible the methodology and its components are.
Best Project Methodology Practices
To ensure a project's success throughout the entire methodology, project managers and project office managers should adhere to the following recommended best practices when selecting, building, or tailoring a project management methodology:
Use standard-proven processes and techniques.
Draw on best industry practices and trends.
Use best practices to reduce common pitfalls.
Look at implementation time and cost reduction.
Minimize excess templates and administration.
Consult industry leaders and subject matter experts (SMEs).
Acknowledge the best path for project implementation.
Recognize what should and should not be implemented.
The following summarizes four key principles in methodology design that should be reinforced:
Use larger methodologies for larger teams.
Use denser methodologies for more critical projects.
Weight is costly.
Interactive, face-to-face communication is most effective.
Methodology Utilization
When using any project framework methodology, ensure that it doesn't become bureaucratic and so administrative in detail that it actually stifles any sense of creativity or overrides common sense. For example, you have a project that must be completed within four months. You have to design and deploy a new product. As project manager, you understand that you cannot spend all your time creating elaborate documentation and hold meetings to create new processes. Time is against you; therefore, it would be wise to first adopt the correct methodology. Developing the organization's project management framework is one of the core foundations of any business to ensure project success. This framework should include:
A total project management approach from start to finish.
The key phases that the company would possibly use.
Inclusion of quality gates or checkpoints during each phase.
Necessary review points between each phase.
Preproject and postproject phases (e.g., sales, operations).
Project templates.
Project processes per phase (i.e., change control, risk).
Using a proven project framework based on industry best practices and tailoring that approach to fit your organization's culture and practices are the keys to success. In the following section of this chapter, we review different types of methodology frameworks used by industry today.
Rational Unified Process (RUP) Project Framework
The Rational Unified Process, or more affectionately referred to as RUP, is a customizable project methodology framework aimed primarily at software development. It is a complete software development process framework that comes with several out-of-the-box examples. Processes derived from RUP vary from lightweight—which address the needs of small projects—to more complex heavyweight projects. To date, projects of all sizes have successfully used RUP.
This methodology enhances team productivity and delivers software best practices to the project team through a set of components, which in turn consist of guidelines, templates, and best practices from thousands of development projects. From large-scale enterprise to agile projects, RUP allows organizations to develop projects more rapidly and deliver quality even when using this process. Table 3.1 and Figure 3.2 show key areas that make up RUP.
Table 3.1: The components of the RUP framework 4 phases
8 iterations (minimum)
9 workflows
57 activities
270 activity steps (approximately)
114 artifacts
38 roles (up to 38 people)
Figure 3.2: RUP project management process. Source: Life Cycles of the Rational Unified Process. Reprinted with permission.
RUP is not merely a process. It is valuable because it embodies many of the best project management practices available today, thereby making it a flexible framework to which project managers can apply their solutions. In other words, you could consider RUP to be a road map for project managers, analysts, testers, and so on. This allows resources to use a common project management terminology and a component "kit" on how to manage projects. If you already know project management, RUP merely becomes a checklist. However, if you are new to project management, RUP gives you a nice overview. Companies such as Wells Fargo and Merrill Lynch and numerous others have used RUP successfully (see Figure 3.3).
Figure 3.3: RUP cycle. Source: Life Cycles of the Rational Unified Process. Reprinted with permission.
The preferred approach to using RUP is to first determine what is missing from the organization's project management environment. After this assessment has been completed, decide how much change the organization can handle. For example, if a company's biggest problem is requirements gathering, RUP offers this process. When this company starts using RUP, you can reassess how successful their requirements-gathering process has worked. Over time, a RUP-based project goes through four distinct phases: inception, elaboration, construction, and transition. Each phase contains one or more iterations. In each iteration, efforts are expended in various amounts to each of several disciplines (or workflows) such as requirements, analysis and design, testing, and configuration management. The key advantage of RUP is reduction of risks (see Figure 3.4).
Figure 3.4: RUP life-cycle phases comparison. Source: Life Cycles of the Rational Unified Process. Reprinted with permission.
Virtually any company can use and customize RUP to suit the needs of its projects. This implies that RUP is as heavy or light as the project wants to go. The implementation of RUP could take from a few weeks to a few years, depending on how much process is required. Above all, use common sense when implementing RUP, as no major tools and techniques are needed. In the future, many companies will use RUP as a project management framework, whereby they can "hang" their best practices. RUP also provides information to help in using other Rational tools for better software development, but does not require the Rational toolset for effective application to an organization. It, therefore, allows you to tailor the process if none of the "out-of-the-box" road maps suit your organization or project. RUP emphasizes the adoption of certain best practices of modern software development as a way to reduce the risk inherent in developing new software. These best practices are:
Develop iteratively.
Manage requirements.
Use component-based architectures.
Model visually.
Continuously verify quality.
Control change.
PRINCE2 Project Framework
PRINCE2 is an acronym for Projects in Controlled Environments (second version) and is now the United Kingdom's de facto standard for IT project management. The Central Computing and Telecommunications Agency (CCTA) originally developed this structured project management methodology, which now forms part of the Office of Government Commerce (OCG)—a government agency—for the development and implementation of IT projects. In fact, this methodology is now so popular that many companies hire only PRINCE2-certified project managers. More and more companies are moving toward adopting this as their standard project approach. Companies such as British Rail, Nat West, Hitachi, BT, London Underground, and Royal Mail, among many others, benefit from using PRINCE2. Some of the many features of this methodology are:
A defined project management structure.
Flexible decision-making points.
A system of plans for resources and technical issues.
A set of control procedures.
A focus on products—deliverables to the client.
A focus on project deliverables throughout the project.
This methodology can readily be applied to non-IT projects as well; therefore, even the construction industry can use this methodology. It is a project management methodology specifically designed to be generic and independent of any particular project type and complexity. This makes PRINCE2 methodology even more interesting to consider. It is nonproprietary, easy to use, and, with some basic training, an excellent approach. Similar to the Dynamic Systems Development Methodology (DSDM) described in Chapter 4, its use is dramatically on the increase in both the public and private sectors. A feature in PRINCE2 not seen in other methodologies is the concept of assuring progress from three separate but linked perspectives. Most organizations that adopt PRINCE2 choose it primarily for its wide applicability and use the pieces that actually "work for them."
Figure 3.5 shows that PRINCE2 is a process-orientated approach for project management. Each process has its inputs and outputs with associated project tasks and activities to be carried out. The methodology shows us that a project is decomposed in manageable phases, allowing efficient command and control. For example, look at project planning. This phase is mainly interested in focusing on results rather than planning when the activities will be done. PRINCE2 is largely driven by its business case (see templates), which describes the business justification, rationale, and motivation for the project. The same applies to all phases shown in the figure. Integrating this methodology into a company's existing culture and processes may require the insight and assessment by certified PRINCE2 project managers, who are knowledgeable of this methodology.
Figure 3.5: PRINCE2 life cycle.
On the upper tier of the illustration, note that the project(s) may report to a corporate program management function. Start at "Directing a Project," which runs from the start-up of the project until the close. This process is aimed at the project board, who manages by exception, monitors via reports, and controls through a number of decision points.
PRINCE2 Phases
The key processes of the project board are these four main areas:
Initiating (starting the project on the right foot).
Stage boundaries (commitment of more resources after checking results reached).
Ad hoc direction (monitoring progress, providing advice and guidance, and reacting to exception situations).
Project closure (confirming the project outcome and controlled close).
This process does not cover the day-to-day activities of the project manager. In the middle tier, we find the phases, which are equally important to any project manager wishing to adhere to this methodology. The phases are:
Starting up a project. The first process in PRINCE2 is a preproject process, designed to ensure that the prerequisites for initiating the project are in place. The process expects the existence of a project mandate, which defines in high-level terms the reason for the project and what outcome is sought. Start-up of a project should be very short and should include the following:
Ensuring that the information required for the project team is available.
Designing and appointing the project team.
Creating the initiation stage plan.
Agreeing whether there is sufficient justification to proceed with the project.
Establishing a stable management basis on which to proceed.
Documenting and confirming that an acceptable business case exists for the project.
Ensuring a form and accepted foundation to the project before starting work.
Agreeing to the commitment of resources for the first phase of the project.
Providing the baseline for the decision-making processes required during the project's life.
Ensuring that the investment of time and effort required by the project is made wisely, taking in account the risks to the project.
Managing stage boundaries. This process provides the project board with key decision points on whether to continue with the project. The objectives of this process are to:
Assure the project board that all deliverables planned in the current stage have been completed as defined.
Provide the information needed for the project board to assess the continuing viability of the project.
Provide the project board with information needed to approve the current phase's completion and authorize the start of the next phase.
Record any measurements or lessons that can help later phases of the project(s).
Controlling a stage. This process describes the monitoring and control activities of the project manager involved in ensuring that a phase stays on course and reacts to unexpected events. The process forms the core of the project manager's effort on the project and handles the day-to-day project management tasks and activities. Throughout each phase, there is a cycle consisting of:
Authorizing work to be done.
Gathering progress status on work.
Watching for changes.
Reviewing the situation.
Reporting.
Implementing the necessary corrective action.
Managing product delivery. The aim of this process is to ensure that planned products are created and delivered, by:
Making sure that work on products allocated to the team is effectively authorized and agreed on.
Ensuring that the work conforms to the requirements of interfaces identified in the work package.
Ensuring the work is done.
Assessing work progress and forecasts regularly.
Obtaining approval for the completed products.
Closing a project. The aim of this process is to execute a controlled close to the project. The process covers the project manager's work to wrap up the project either at its end or at premature closure. Most of the work is to prepare the input for the project board so that they may sign off the project. The objectives for this phase are:
Checking the extent to which the objectives set out in the project initiation document have been met.
Confirming the extent of the fulfillment of the project initiation document and the client's satisfaction with the deliverables.
Obtaining formal acceptance of the deliverables.
Ensuring to what extent all expected products have been handed over and accepted by the client.
Confirming that maintenance and operation arrangements are in place (where appropriate).
Making any recommendations for follow-up actions.
Capturing the lessons learned from the project and completing a lessons learned document.
Preparing the end project report.
Notifying the host organization of the intent to disband the project resources.
On the lowest tier, we find the planning process. It is important because it considers key project processes, which are:
Planning an initiation phase.
Planning a project.
Planning a phase.
Producing an exception plan.
Overall, PRINCE2 proves to be a sensible and practical project methodology. The best feature is that no license is required for using this methodology, except one obtaining the required documentation. Additionally, it is not necessary to purchase special project management tools, as PRINCE2 allows use of any project management tool to manage projects. Project managers who are familiar with PRINCE2 are able to:
Establish terms of reference as a prerequisite to the start of the project.
Use a defined structure for delegation, authority, and communication.
Divide the project into manageable stages for more accurate planning.
Ensure resource commitment from management is part of any approval to proceed.
Provide regular but brief management reports.
Keep meetings with management and stakeholders to a minimum but schedule them at vital points in the project.
Required PRINCE2 Artifacts
There are essential artifacts required by a typical PRINCE2 project. First, the business case artifact used by PRINCE2 is a reasoning or justification of the project. After all, as mentioned in Chapter 1, companies must focus on pursuing only those key strategic projects that produce innovative products and services. Together with this, project managers must ensure that all project risks be identified in the business case.
The business case should be routinely updated to reflect any change to the project, should new risks be identified. It is true that much time is spent on the business case, but this ensures proper planning and coordination. Therefore, the business case gives a clear picture of what is to be delivered. At the start of a project, the product specification is drawn up, which reduces the risk of delivering the wrong product. Although the PRINCE2 methodology does not directly deal with social or "soft" management skills, such as negotiations, presentation techniques, coaching, or leadership, it is necessary for a project manager to possess these skills to be successful.
If your company plans to implement PRINCE2, you would most likely start by training your key staff on the best practices and detail on the methodology and then provide overview training to those who would need to be aware of the methodology. Advantages and disadvantages of using PRINCE2 are discussed in the following sections.
Advantages of PRINCE2
The method is independent of the application domain such as IT software development, marketing, building and construction, and change management. Domain-specific methods such as DSDM, product development methods, or domain-specific standards can be applied in the PRINCE2 teams. This way, the method is generically applicable to any project. PRINCE2 provides a layer over the disciplines that are needed in the project because it defines a flexible "project language" that suits multidiscipline project teams. Therefore, the method bridges the gap between IT and business, for instance.
The method is in the public domain, and services (training, consultancy, and tools) can be obtained from several independent suppliers.
The method has active user groups in the United Kingdom and the Netherlands.
The method is applicable to small and large mega-projects.
The method focuses on project results in terms of the standard time, cost, quality, and functionality parameters but also has a strong focus on business case and the benefits the project results deliver.
The method integrates change management that controls the changing environment.
The method uses management by objectives and management by exception approaches.
Disadvantages of PRINCE2
It is a method and not a cure for any project. People who use PRINCE2 should continue to think.
Some people apply and interpret the methodology in a rigid way and do not tailor it to the project at hand. Huge bureaucracies might be constructed if all checklists are used in a paper format and not adapted to the project.
Human factor or soft issues are not within the scope of the methodology and are desperately needed for project success.
System Development Life Cycle (SDLC) Methodology
Many projects follow the classic waterfall approach, and it is fairly straightforward to conceptualize. No rocket science is needed here. You simply have to focus on the logical progression of what needs to happen on the project. The SDLC is in essence a waterfall methodology. Successful companies such as Johnson & Johnson, Novartis, Adventis, American Express, and Nokia use and adhere to an SDLC approach. Table 3.2 describes the basic methodology phases available for a project.
Table 3.2: Simple approach Phases
Phase Description
Critical Plans
Discovery
Researches and refines organizational objectives for the project.
Strategy/roadmap
Design
Provides the design and solution to the organization.
Blueprint design
Construction
Constructs the product against the design blueprint.
Project plan
Implementation
Implements the tested solution into the organization.
Test/deployment
Follow-up
Ensures that solution is rolled out smoothly and irons out issues.
Maintenance
The project manager should pursue the options and choices of which project methodology to use, depending on the engagement. Tables 3.3 and 3.4 reflect similar methodologies available to project managers when working with a client and deciding which approach to adopt.
Table 3.3: Complex approach Phases
Phase Description
Critical Plans
Definition
Identifies the project team and lists assumptions.
Project schedule
Data collection
Collects data for the intended solution.
Analysis forms
Develop model
Develops a conceptual model of the solution.
Specification
Verification and validation
Confirms that solution performs as required and compared to all measurable results.
Validation plan
Optimization
Ensures that the solution meets predefined success criteria.
Optimization plan
Delivery
Delivers the solution to the client.
Deployment plan
Table 3.4: Generic approach Phases
Phase Description
Critical Plans
Needs analysis
Determine exact client requirements.
URS, Business case
Project concept
Establish business objectives and deliverables from the client.
Project definition
Project design
Start designing the solution for the client.
Specifications
Training
Provide training to users in the client organization.
Training plan
Project delivery
Implement the project per the identified project schedule.
Deployment plan
Project support
Address all support-related aspects of the project.
Support plan
For numerous SDLC-type projects today, the trend and style of these methodologies frequently involve completing one phase after the next. Many are monolithic in nature; they are time consuming and some methodologists are calling these formal giants the dinosaurs of project methodologies. SDLC methodologies at least provide a framework for completing projects, but it's not that these methodologies follow the often-quoted maxim "Ye shall release early and release often"; rather, they rely on "Ye shall wait till each phase is complete before releasing resources for the next." In today's complex digital world, where faster is better, project managers struggle to complete projects where complex, unknown technologies are being used. Clients do want to see results much earlier than before. They insist that you follow a project approach, but they want to see results much more quickly and want deliverables to be delivered sooner. My advice is to go through the various approaches mentioned here and select one that is best suited for your needs, and tailor it accordingly. In addition, refer to Chapter 4 of this book to start a journey into methodologies (see Figure 3.6).
Figure 3.6: Complex life-cycle methodology.
Approach
Needs analysis. This phase is used to determine the specific client requirements for the proposed solution. The needs analysis aids in identifying the exact business and functional requirements.
Project concept. The project concept establishes the business objectives and assumptions, risks, and deliverables into a project concept, which is usually documented and presented to the client for acceptance.
Project design. This phase allows the project design or development team to begin creating or formulating the design for the solution.
Project training. The training phase is an important part of this methodology because it includes training as part of the project. It assumes that training for the user is necessary.
Project delivery. The implementation of the project occurs after training has taken place. This phase ensures that the project is delivered at the relevant location(s) within schedule.
Project support. This phase of the project ensures that the necessary support for the solution has been coordinated and managed. Tasks such as support level agreements (SLAs), escalation processes, and contact lists are performed.
Solutions-Based Project Methodology
Solutions methodologies offer consulting companies the opportunity not only a way to work with clients but also a structured manner in which to deliver projects. They form the standard approach to doing the work. As each solution is different from the rest, it becomes important to adhere to a consistent manner in which projects are managed and executed.
Ray Lane of Kleiner Perkins Caufield & Byers states:
E-business is about rebuilding the organization from the ground up. Most companies today are not built to exploit the Internet, their business processes, their methodologies, their hierarchies, the number of people they employ ... all of that is wrong for running an e-business! (p. 1)
There are numerous e-commerce project and development methodologies available today. They vary largely because of their architectures, technology, and target dates. At a minimum, e-solutions methodologies should consist of the following phases.
Objectives.
Strategy.
Design.
Content.
Development.
QA.
Test.
Launch.
Maintenance.
Creating a Basic Methodology
If you are new to methodologies, you should start with a simplistic approach for your project. The first step is to list a few key phases you think suit your type of business. In the following example, we start building a methodology. Assume you have a small project team in your company and that your aim is to avoid any lengthy documentation or additional steps that will impede project delivery. You can always start elaborating as your project starts gaining momentum. For the purpose of the example, I have randomly selected three basic phases of our methodology:
Explore. Here you need to ensure that the focus remains on completing the business requirements for the upcoming solution. This includes obtaining project information, meeting with your client, and creating a list of assumptions and a project brief or business case. You should drill down into some level of analysis and determine what the project scope is or is not.
Develop. During this key step, start creating at least the project plan, together with any technical specifications you need to build your product. This may include case diagrams and flowcharts. Additionally, during this phase, the role of the deployment plan is highlighted.
Execute. During the execution phase, the physical solution is developed and tested to the point where the solution is rolled out to the client.
With the main phases documented, we need to identify the minimum artifacts or project templates needed. Table 3.5 shows that we need at least a business case document during the "explore" phase. After you have the templates defined and in place, assess which processes you need to support this methodology. Assume that your company or project will be purchasing considerable hardware and services from different vendors. In this case, you need to ensure that you have a procurement and financial process in place to make things easier. If these basic processes are not in place, it is likely that you will be spending more time doing administrative work than managing your project.
Table 3.5: Solutions-based models Basic Phases
Phase Description
Basic Artifacts Needed
Explore
Examine the deliverables needed, as well as resources.
Business case
Develop
Develop solution against specification.
Technical specification
Execute
Implement the solution.
Deployment plan
After the processes have been identified and established, run a simulation or demo to see that everything works the way that you designed it to work. Tweak the methodology by either adding or deleting pieces to the methodology. If your company or project is small, you want to be flexible and able to communicate to fellow team members in an efficient manner without any complexity. Many companies make the fatal mistake of having reams of documentation do the communicating between parties instead of face-to-face communications. But our example is fine. We have kept the methodology to a minimum set of templates and processes, and we have our project team sitting together in a comfortable and relaxing work environment.
As our team or project becomes larger, it will require additional coordination and, regrettably, slightly more documentation. In addition, depending on the technology, we want a highly dynamic project environment that can create this solution quickly (e.g., we want to create a national database that collects and interprets intelligence data from multiple government agencies).
Creating Hybrid Methodologies
There are circumstances in which it may be necessary or appropriate to combine two methodologies to create one perfect tailored methodology. Sometimes, it is more feasible to dynamically build a methodology from other methodologies. You may find yourself starting out using a waterfall methodology, then during the life cycle of the project (i.e., development), you realize that using a RAD methodology may be more appropriate. Remember that each methodology offers its own set of strengths and weaknesses from a methodologist's perspective. In the Air Force, to keep mission-critical aircraft serviceable, the "one-from-two" principle is sometimes employed—two unserviceable aircraft are stripped down and critical parts are used to build one fully functional aircraft tailored for a specific use. This is the concept of the hybrid approach.
For any project manager, this option should remain open, but with sudden change comes risk. Points of safe cutover from one approach to the other must be clearly defined, and the project manager should assess the impacts on schedule, cost, and resources. There are issues with the user involvement in the different streams of development, project management issues including possibly different approaches to change requests in the two approaches, and organization management issues. This is permitted, provided the project management framework in the company can support various development methodologies
Project Methodologies Explained
Project Methodology Overview
Key decision makers must often determine whether a universalized project life-cycle methodology is sufficient for all their projects. The answer to that question is an unequivocal no! Very few people are capable of creating a state of-the-art, concisely defined, phenomenally small, highly prescriptive, measurement-intensive, fast, and cost-efficient methodology allowing project managers greater performance improvement (consisting of an expertly designed/optimized family of policies, procedures, plans, specifications, forms, logs, and metrics). Every company has its own process flow diagram. This flow originated from a methodology created to ease implementations of new technologies or new project ideas. These process flow diagrams have many different stages, all similar in nature.
Even dynamic project-based organizations such as Accenture, KPMG, Deloitte Touche, RCG Information Technology, Bechtel, and Keane are far more than a collection of individual projects. If that were all they were, they wouldn't be multimillion-dollar organizations. They all use various arsenals of project methodologies for each solution they undertake. Companies are becoming very much like small film studios. Each project is a "movie" all by itself and has its own "director" and "script." The movie needs project funding to begin and is short lived; project teams are also short lived, and, amazingly, in this brave new model, they follow a unique project methodology, because if they don't, no one will invest in a "movie" or project. Therefore, projects need to be innovative, they need process, and they need to adhere to the "script" or methodology. Each movie script is different from the next; this is where we focus our efforts throughout the book.
By simply assessing those project methodologies that exist today, we see that a universal project approach simply won't work. The main reasons that a single "be-all-and-end-all" methodology won't work from industry to industry are differences in:
Life cycle.
Market sector.
Product.
Size.
Technology.
Situation.
For instance, a nuclear plant or space shuttle project has very specific heavyweight life-cycle components (e.g., work breakdown structure, activities, tasks, task durations, priorities, skill sets, and economics) compared to a small construction project. In other words, they use different phases and activities on their projects (i.e., communications and navigation equipment, operating systems, and a variety of technologies).
In addition, the life cycles for construction projects (e.g., bridge building), compared to information systems projects (e.g., three-tier architectures), may be vastly different from one another. This means much tweaking is needed if you have to accommodate every kind of project. Hence, different methodologies are needed. Therefore, we have a catch-22 situation—various technologies and industries make it very challenging to design a one-size-fits-all project life cycle. It does not seem likely that an individual project manager or executive can actually design a highly operational, functional project methodology that meets the needs of every single project—irrespective of its technology or industry. Hence, some creative genius is needed to bridge this gap. A project life cycle is, therefore, a collection of project phases. Project phases vary by project or industry, but some general phases include:
Concept.
Development.
Implementation.
Support.
Remember that products also have life cycles. Many companies have project managers or executives who are unwilling to follow systematic project methodologies all of the time. Instead, they tend to rely on standard business activities to get them through the project. They are simply trying to keep up with all this talk of project methodologies and associated processes and techniques. Questions such as "Why are there so many methodologies?" and "Which one do we use?" often arise. Over the years, even those involved in managing projects have observed that projects have common characteristics that can be formalized into a structural process, which allows them to manage projects more effectively.
Each phase can typically be brought to closure in some logical way before the next project phase begins; and each phase results in discrete milestones or deliverables, which provide the starting point for the next phase. Project methodologies should be structured to take advantage of the natural phases that occur as work progresses. The phases should be defined in terms of schedule and specific accomplishments. Define how you will know when you have finished each phase and what you will have to show for it.
Cost and schedule estimates, plans, requirements, and specifications should be updated and evaluated at the end of each phase, sometimes before deciding whether to continue with the project. At times, you may want to hold off or cancel the project. Large projects are usually structured to have major program reviews at the conclusion of significant project phases. These decision points in the life of a project are called major milestones. Figure 2.1 shows how project phases are somehow linked to one another. This is the basis of how project phases, once incorporated, form a typical project development methodology.
Figure 2.1: Depiction of general project methodology phases.
Milestone decisions are made after conducting a major program review in which the project manager presents the approved statement of requirements, acquisition strategy, design progress, test results, updated cost and schedule estimates, and risk assessments, together with a request for authorization to proceed to the next phase. The early project phases tend to shape the direction for all further efforts on the project. They provide requirement definitions, evaluation of alternative approaches, assessment of maturity of technologies, review of cost, schedule and staffing estimates, and development of specifications.
A relatively short-term or technically straightforward project may have only a few basic milestones or deliverables following a (1) proposal, (2) feasibility study, or (3) business case. Nevertheless, the project manager should report to clients and executives at intervals to keep them up-to-date on project progress, thus ensuring project direction. (See lightweight methodologies in Chapter 4.)
On small projects, if no formal agreements are written, the project manager should deal with clients and executives in an informal, yet somewhat structured and logical, manner. This means managing expectations and making clear agreements about what will be produced and when. You simply cannot do this on the fly.
On long-term projects, you may find project phases take place over many months or even years, and, in this case, it is vital to provide interim deliverables to give the clients and executives a sense that work is being accomplished, to provide an opportunity for feedback, and to capture project successes in documented form. This is exactly why a project methodology works. How else are you going to do this? (See heavyweight methodologies in Chapter 4.)
It is wise that the project processes be built around the specific project methodology. Particular care should be given to defining the work to be accomplished in each phase. This should include definition of the deliverables to be produced, identifying testing and demonstrations to be completed, preparing updates of cost and schedule estimates, reassessing risks, and conducting formal technical and management reviews.
Background to Project Methodologies
Project management has grown from the early initiatives in the U.S. defense and aerospace sectors in the late 1950s and 1960s. The U.S. Department of Defense and NASA achieved early project management successes—mainly promulgated through their internal policies, procedures, and lessons learned. From this flowed numerous white papers, articles, seminars, and training programs that expanded the project management genre, although much of the theory centered around the use of tools and techniques, such as:
PERT/Gantt charts.
Critical path.
Scheduling techniques.
Organizational issues.
Conflict management and others.
From the early 1970s, project management societies began to provide communication on the discipline, basically through journals, conferences, and seminars. This continued until the mid-1980s when, first, the U.S.-based Project Management Institute (PMI) and, later, the U.K.-based Association for Project Management (APM), embarked on programs to test project management professionalism. This brought about certain guidelines and bodies of knowledge (e.g., PMBOK, APMBOK), which addressed some methodology but did not address every industry and type of methodology. Other organizations developed their own versions of a project methodology.
In the pioneering days of project management, it was common practice for project staff or managers to devise their own methods of moving through the life cycles of their projects, which were often influenced by information technology, engineering challenges, or financial constraints. It was a time when a project was driven by the events that occurred while on the job. This was fine for certain projects, but it led to the failure and delay of many projects because of problems that started to show (1) poor or inconsistent project designs, (2) poor project analysis, and (3) ineffective project communications. It seemed projects lacked the rigor and key ingredients to make them more effective. Sometimes, it takes a complete outsider to show how to expedite projects more quickly than before, in innovative futuristic ways. Look at what BMW has done—you can today log onto their Web site and purchase a customized vehicle, specified by you instead of selecting one from a standard showroom floor model. The production-to-delivery process is drastically reduced and flexible.
A great analogy of the need for appropriate control is found in Formula One racing. Here, the powerful cars have braking systems to enable them to go faster rather than to slow them down. Likewise, in different industries, appropriate levels of control allow an organization to grow and flourish within appropriate boundaries. Both project managers and executives need to understand the impact that new developments in technology are having on business from the project, operational, and risk points of view. It is possible to split the responsibilities of methodologies into three broad areas:
Managing project performance.
Managing the project life cycle.
Managing the resources and communications aspects.
Having the right processes in place to address these areas is a challenge faced by every project manager. I address each of the components of the guidelines because I believe they provide a well-researched and practical solution to this project management challenge.
Everywhere I go, clients ask the same question: "How do our project practices compare with those of our competitors or with those of our peer organizations?" Until now, this information could be obtained only from consultants, market research, or other third-party sources. The project methodology maturity models provide information whereby an organization can carry out a self-certification to grade its own processes from virtually nonexistent to the purist levels, principally as a means of identifying improvements and actions to take.
It is essential that the management of any organization identify and articulate its critical success factors (CSFs). These are the ground rules that determine the appropriateness of the environment in which the organization operates. The CSFs set out the culture, behavior, and actions for management to take to achieve its objectives relating to project methodologies. The guidance provided in the chapter should be easy to apply in practice.
Assessing the Project Methodology Ecosystem
In the context of this book, a project management methodology is considered part of an overall larger ecosystem. The ecosystem can be viewed as a "give and take." Whenever you "touch" the ecosystem, there are things that are bound to occur. Table 2.1 lists what the ecosystem consists of.
Table 2.1: Project management ecosystem components Component
Example
Project standards and best practices
PMBOK, RUP, Java
Supportive processes
Change control
Project management infrastructure
PMO
Templates
Project brief
Performance metrics
ROI, BCA
Project activities
Testing
Project techniques
WBS, Use cases
Project tools
MS project
Project roles and responsibilities
Project teams
Core project methodology framework
PMLC process
Development methodologies toolset
Prince2, XP, Spiral
Figure 2.2 shows the makeup of the project management methodology ecosystem. Remember that any sudden change to the core methodology will result in a change to many other areas, such as templates and a ripple effect on supportive processes. Project managers wanting to deploy any methodology in an organization should realize this natural effect.
Best Practices for Project Methodologies
Most projects share a common life cycle. This is not to say that these projects are all designed and executed the same way, but they remain universal, as they pass similar phases during the life cycle of the project. When dealing with any methodology, ask the following questions:
How do we ensure that our projects develop and deliver successful products? Is the methodology able to accurately capture requirements and effectively manage the project against those requirements?
How can we deploy projects more quickly, avoiding overruns and poor performance, and for better value, lower cost, and better functionality?
When looking at organizational project methodologies available today, we realize that certain methodologies work well and some do not. Some are more proactive than reactive. For those that are not well planned, the organizations will simply not have success with those methodologies. Competitors will overpower them and deliver products faster to the market, and the organization will face competitor lockout. Some of the following best practices are needed before designing, purchasing, or benchmarking a prospective solution:
Provide standard proven processes and techniques.
Benchmark or leverage the best that your industry has to offer.
Create a list of "must-have" components.
Recognize the necessary processes you need to complete projects.
Consider the best cost and time schedules for your methodology.
Determine what core competencies are important.
Configure resources.
Integrate with suppliers and parties.
Understanding Project Life Cycles
After the project life cycle is defined, the project budget and technical aspects must be managed together. And this is important. Can you imagine delivering a project within cost and schedule but that the project does not meet its technical specifications? I think not—a project life cycle must be efficiently managed if the project is to be successful.
An iteration is defined as a distinct sequence of activities with an established plan and evaluation criteria resulting in an executable release. If we examine the set of illustrations describing the waterfall approach, we can see that an iterative approach does have advantages over a straightforward waterfall approach. This analogy should help reveal other ways to manage projects.
On many projects, where dates have been preset either by sales executives or senior corporate stakeholders, project managers often do not have the luxury of changing the fixed end date. Hence, how do you meet a fixed end date? Would a System Development Life Cycle (SDLC) or a Rapid Application Development (RAD) approach work better for you (i.e., incremental versus an iterative approach)?
Delegates attending my project presentations often ask: "How do I make my view of the world work, when working with new technology projects?" "What methodology do I follow?" I always respond by stating that you have control over only the inputs you receive, and you define your projects based on those constraints. It's not up to you to start reorganizing the organization just for your project. First, see what's within your boundaries. Then act from there.
CIPOC—A Conceptual Approach
When I try to place any project life cycle or methodology into perspective, I always go back to the Client, Input, Process, Output, Clients (CIPOC) approach, a slight deviation from the "supplier" concept. It is one of the greatest examples of a primer that gives a high-level conceptual view of the way all project methodologies fit into the grand scheme of things (see Figure 2.3).
Figure 2.3: CIPOC technique to reflect methodology usage.
CIPOC works like this. A client has certain requirements for which he or she needs a certain solution. This can be a new skyscraper, submarine, spacecraft, software, or even a rock concert. It doesn't matter what kind of project. These client requirements are formed into inputs, which in turn serve as the defining moments or starting point for the process—which can be virtually any methodology you want to use (e.g., Waterfall, SDLC, PACE, RUP, XP, MIL-STD-1612, PRINCE2). The project manager uses his or her chosen methodology and proceeds to design, build, test, and deploy the solution. These are the control points. When complete, an output has been generated that is then accepted by the client. The client can be involved anywhere in the CIPOC approach; the client readily provides feedback at any stage.
All assumptions must be made upfront at the onset of the project process start. This is one of the control points. If the project manager cannot control the assumptions, the project may come back and bite, irrespective of methodology employed.
If you need 500,000 kilowatts of power in a remote location, how do you do it? How do you meet your client's needs? You need an approach, and, typically, you would follow a CIPOC approach. Similarly, the Winter Olympics held in Salt Lake City was a phenomenal project itself. The Olympics organizers, too, would follow the CIPOC approach.
If we examine major companies such as Ernst & Young, RCG Information Technology, and IBM, we find that these major solutions companies have total "soup-to-nuts" project methodologies in place. These project methodologies embrace everything from the initial sales call, defining the solution, right through to deployment. They can identify the appropriate resources needed per project life-cycle phase (i.e., account executive, recruiter, designer, tester, project lead). These methodologies are well documented. If we examine other companies (e.g., home builders, software developers), we find that many don't have the luxury of such an elaborate project methodology in place. They simply adhere to projects in their own informal manner.
Understanding Project Model Terminology
Project Feasibility and Justification
The project manager's first task is to become familiar with the feasibility of the project. He or she should reaffirm to his or her own satisfaction the findings of the original study, which may have been some time ago, certainly before he or she accepted the job. Thus, reaffirming the feasibility and justification of the project is crucial.
User Requirements
The most important phase in any project is to find out what is actually needed. Without proper establishment of the requirements, no one is certain what is really required. This is not covered fully in the Project Service Request (PSR); therefore, work and effort are needed at the start of the project. Subsequent time may be wasted if the user requirements are not established and understood.
System Design
After establishing and agreeing on the requirements, a high-level design of the main functions of the system can be produced. This is followed by considering the development of each of these main functions in more detail.
Detailed Design and Buy or Build
These follow the established meanings found in most development models. Each activity in the work breakdown structure (WBS) is given sufficient individual attention so that it is designed in detail ready for building. These phases apply equally to the design and creation of documentation as well as software. They also apply to hardware, except that items needed to run the software will be ordered from suppliers instead of building the items. The hardware design is determined by the software requirements.
Acceptance
The acceptance phase is the running of integration tests at system level to prove all documentation, software, hardware, and other equipment. These tests must be designed carefully and not left to the suppliers (of equipment, software, and documentation) to construct. Otherwise, we find that suppliers may test only the parts that work and may deliberately not consider the whole system, which may lead to problems for the end users. Notice that testing occurs throughout the project—not delayed until a single testing phase when and where it would be too late to rectify faults efficiently. This phase is about testing to accept the whole system, not testing to see if it works.
Commissioning
Every component is built, tested and integrated. Commissioning is the setting to work of the proven and integrated system. This is the time to introduce the end users to their relevant parts of the working system and then cut over to the live system. During this stage (or even before in some projects), user training takes place and the help desk is set up.
Completion and Post-Implementation Audit
When all stages are completed to the satisfaction and agreement of all parties, it is important that the project be recognized as complete. At this stage, it is crucial that the project manager document the following before starting another project:
Job descriptions for operations staff.
Job descriptions for systems staff.
Working practices for operations and systems teams agreed on by management, operations manager, and systems manager.
Rolling plan for update, upgrade, and replacement of equipment over the next two to five years.
A plan to ensure that all documentation is complete and signed off.
A plan to ensure that all contractors, subcontractors, and self are paid up-to-date.
A postimplementation audit date for three to six months after project close-down.
In the postimplementation audit (PIA), the project manager returns a few months after responsibility for the new system has been assumed by the client (i.e., steady—state). The actual audit procedures should be determined initially, indicating that a team will return to see whether the system is working as designed. Most of this audit consists of ensuring that the project team is adhering to established working practices. It is quite surprising how people misinterpret documented procedures and invent ways around problems. These issues of documentation standards are beyond the scope of this book. The PIA has rarely been carried out in the past and is only now gaining a reputation for its usefulness.
Roles and Responsibilities on a Project Life Cycle
Table 2.2 reveals typical roles and responsibilities that one would encounter on a project. The larger the project, the more roles and responsibilities would be added.
Table 2.2: Roles and responsibilities on the project life cycle Roles
Responsibility
Verify resource allocation
Project Manager
Assign individual responsibilities
Project Manager
Verify project scope and change control
Project Manager
Estimate work packages and time to complete project
Project Manager
Monitor and control life cycles
Project Manager
Reduce uncertainty
Project Manager
Improve decision-making process
Sponsor
Attain effective solution
PM/Analysts
Establish continuous improvements to project
PM/QA
Maintain focus of project goals and objectives
Sponsor/PM
Provide continuous feedback to executives and stakeholders
Project Manager
Manage project plan
Project Manager
Avoid possible risks and issues
Project Manager
Maintain focus of schedules, budgets, and work plans
Sponsor
Likes and Dislikes of Project Methodologies
Often, one person may give a project manager the best kudos and praise for adopting a certain project methodology, but too often, the kudos arise mainly from the ranks of the management layer. Methodologies are like an onion—just when you peel off one layer, you discover another layer waiting for you. Some of the pros and cons seen by managers and nonmanagers working on projects are listed in Table 2.3.
Table 2.3: What managers and nonmanagers think of methodologies Project Managers Think
Nonmanagers (Team Members) Think
Methodologies define a set of deliverables.
Methodologies do not really represent what actually happens.
Methodologies adhere to a structured approach.
Phases are often overlapping with other phases.
Methodologies bring structure to a chaotic environment.
Methodologies are a waste of time and unnecessary overhead.
This is the way companies should be run.
No one clearly knows the true value of this path.
Methodologies don't always reflect the technical requirements.
Blueprints for Business Innovation
Because the introduction of a project management methodology and its processes possibly needs to be integrated into the existing business processes, it becomes necessary to stop to look at what we need to take care of before simply designing a methodology. Business process reengineering focuses on optimizing existing processes and facilitates the redesign of these processes if they are outdated and superfluous to departments or units, they do not meet clients' needs, or they are causing long delays for meeting organizational strategy.
Look at how Dell Computers is able to reconfigure its production lines for flexible, more rapid market demands. They adapt more quickly than their competitors and apply great methodologies for their solutions. Look at how Walt Disney has moved beyond the realm of its theme parks by having its own line of cruise ships and entertainment—all innovative by design—reflecting that Disney is able to transcend the norm.
In Table 2.4, note that in any organization today, there are existing processes that directly interface with the aims and objectives of what many project managers are trying to do throughout the course of a project's life cycle. Remember that project management is about managing the triple constraints, which are (1) cost, (2) time, and (3) quality. It's not that simple for project or development managers to simply ignore existing processes to get their jobs done. The methodology should be tightly and seamlessly integrated into the existing processes, so much that they complement one another.
Table 2.4: Examples of processes in organizations Process
Function
Affects Project Management
Invoicing and posting of credits
Financial
ü
Purchasing of goods and services
Procurement
ü
Timesheet submission
Financial
ü
Financial monthly reporting
Financial
ü
Salaries
Financial
ü
Legal disputes and claims
Legal Council
ü
Recruitment of staff
Personnel
ü
Strategic prioritization of projects
Projects
ü
Quality control and assurance
QA
ü
Training
Training
ü
Profitability
Financial
ü
Methodology Design
The focus of this section is how project methodologies can be developed to support projects in a company. Developing a project methodology and adapting it to the situation often deal with changes on many levels—changes in culture, processes, and information systems. A culture can provide project teams with a shared frame of reference and facilitate communication. The processes can provide a structure of activities in the projects, which helps new employees and can provide a common language. Information systems may be linked to the process and provide the tools that influence the daily work.
The research is based on active participation during the development of a methodology for product development. The case illustrates the tendency to focus on the process level and underestimate the importance of influencing the culture and adapting the current system to the new envisaged processes. The results are analyzed to provide increased understanding of the success factors when new project methodology is to be developed. The aim is to create a framework that can be used by companies that want to develop a project methodology or improve their existing project methodology.
With any new process, the way an organization works—and its entire culture—changes. Hence, it becomes crucial that the project manager not only develop the project management processes themselves but also create:
Support plans.
Communications plans.
Deployment plans.
These elements facilitate cultural change in a company and are fundamental to a successful project management deployment. You should not "reinvent the wheel" for each client engagement. Tailor project management processes that best suit your needs. The project manager should understand business processes and be able to merge them with current and tested best practices to quickly and effectively produce a tailored, client-specific set of project processes. It's not easy—developing processes is a science in itself. The question is: Do you have time to implement these processes on your own? Or, is your time running out? How much help is needed to design these processes to support your project framework?
Project Methodologies Demystified
We now examine the relationship between methodology size, project size, and problem size. This discussion can be tricky because there is a tendency to think that more people must solve larger problems.
Project size and methodology are connected by a positive feedback loop. With relatively few people, relatively little methodology is needed. With less "weight," they work more productively. With greater productivity, they can address a larger problem with their smaller team and lighter methodology. On the other hand, when more people are assigned to a project, they need more coordination (i.e., more methodology). The heavier methodology lowers their productivity; therefore, more people are needed to accomplish the same work. Methodology grows more slowly than project size, so eventually they get to a point where they can solve the problem and manage the coordination activities (assuming sensible management).
Therefore, for a given problem, you need fewer people if you use a lighter methodology and more people if you use a heavier methodology. However, there is a limit to the size of problem that can be solved with a given number of people, and that limit is higher for a large team using a heavier methodology than for a small team using a lighter methodology (i.e., at some point, you will need both a large team and a heavier methodology). The difficulty is that there is no reliable way to determine the problem size at the start of a project and no way to know the minimum number of people needed to solve it. The number of people varies with the people in question. Finally, as the project grows in size, a different combination of methodology and project size becomes optimal.
To begin to consider what constitutes a good and effective project management or development methodology, you need to clearly understand what phases are available to use, within all the project and development methodologies that face you as a project manager. The most common phases you would likely encounter when discussing or designing a methodology are discussed in the following sections.
Discovery/Concept/Idea
A well-conceived idea is the creative stuff that makes everything important. It's why the project started in the first place. There is no launch if there is no acceptable initial idea. Brainstorming is an effective technique to help you develop a prime idea. Be aware of the effect that the external environment (customers, competitors, market, etc.) has on the idea. In the concept stage, the exact definition of the idea and strategy is derived. The objective is to develop a protocol with defined target markets, product concepts, and attributes.
Engagement/Concept
Because each project is unique and must be approached very differently from the next because of client requirements and demands, in the engagement or concept phase, the project manager and sales executive actually meet with the client and discuss possibilities and begin to extend the communications process between the parties involved. This is often the most important phase as it sets the standard going forward. This can initially be a single occurrence or a series of meetings that brings the stakeholders together. It identifies key role players in the project and starts setting responsibilities.
Analysis/Feasibility
The analysis or feasibility phase determines that the project has been thoroughly assessed and deemed economically or strategically feasible to continue. If the analysis weighs against the project's success, the project is discontinued or returned to executives for further discussions. It is highly recommended that projects be analyzed before commencing to the next phase of the project life cycle or methodology.
Strategy Planning
Every company needs to have a system for deciding on and formulating the necessity and priority of launching any project or product. Whether a new design or new release of software, the strategists need to plan within the framework of the business model. The strategy planning would allow decisions about launching additional projects to support a priority project or delaying certain projects to favor a more important project's getting to market.
Feasibility Assessment
Before committing time and resources to any development, it may be necessary to establish the need for the project. Sometimes, it's not feasible to commit the organization to even attempt the project because it simply duplicates another effort or costs too much to gain a successful foothold in the marketplace. Additionally, the technical feasibility of the project may be unknown, and without performing a proper feasibility study of the technology, the project would result in negative cost and schedule delays.
System Analysis
After the project is launched, it becomes vitally important to establish client requirements to start designing the eventual system or product. At this stage, the project team should use techniques to fully understand what the project should deliver.
Design/Development
On any project methodology, one of the key phases is the design or development phase. The phase represents the solution build. Key staff—such as designers, architects, or engineers—develop a solution based on either partial or full user requirements. This design will form the basic building blocks from which the project team will work.
Deployment/Execution
After the project has been built, tested, and proven to work as designed and specified, the project is ready for installation or rollout. It is during this phase that the product or system is finally assembled and installed. In addition to simply implementing a system, users must be trained.
Testing
This phase indicates the formal testing of the solution. Testing can be done either incrementally or at the end of a development phase if following a waterfall approach.
Quality Assurance
In the quality assurance phase, the solution is validated and tested against the initial specifications of the project.
Training/Education
Before any system or project is fully deployed, users need to be identified and trained. This phase may involve establishing the training requirements for the project and generating either the necessary training courses or documentation.
Rollout/Implementation/Deployment
This phase is the delivery of the solution within the client organization. The rollout takes effect when the system is ready to be installed either in a series of small increments or as a fullblown deployment. During this phase, it is crucial to have an implementation plan and schedule to assist with the details of rolling out the project to the client.
Maintenance/Support/Operations
After the project has been finalized and the product launched, it is considered operational or in production. Therefore, the product must now be maintained. Many products need constant updates or changes. For example, after a new software is launched, it is likely that some updates will be needed. Therefore, the project needs to address exactly how postproject changes will be handled and executed. Considerations such as how incremental changes will be implemented must be resolved. On many other projects, fulfillment and restocking of vital spare parts—including the vendors' support—are crucial in making this project a success. (Methodology support is discussed in Chapter 6.) In this phase, the organization or client introduces operational support for the project once completed. Tasks such as arranging help desk support, service level agreements, and monitoring and diagnostics are performed in this phase.
The Importance of it Methodologies
As many industries use information technology and focus on the development of software, it is appropriate to describe the IT environment to explain why different methodologies are needed for different things. For example, many construction companies that use the standard waterfall methodology are today using IT methodologies—such as RAD—to bring in their predictive and "heavy" schedules more quickly than before. And it appears to be working successfully.
With almost all IT projects today, we typically encounter any one of the following scenarios in which we need to adopt a development methodology. An IT project may consist of three core tiers:
Graphics User Interface tier (front-end). Usually done by visual development languages using tools such as Visual Studio.NET, Java.
Application middle tier. Usually addressed by a business-centric methodology.
Database tier (back-end). Usually accessing one or many databases to retrieve data or information, using tools such as SQL, Java, or object components.
The same development cannot be used for each tier. For example, you are tasked with an IT project in which you have to use only the top layer—the front-end—then you need to consider your specific development options. They may be application specific. The same applies for the other two tiers.
Identifying Your Project Maturity
Many companies are very aware of the important role project management plays in their companies, but many are somehow unable or unwilling to make a transition to develop their project philosophy to the next level. Companies want to know exactly (1) how well they are currently doing and (2) where they would like to be on a project maturity level. After all, a company is more than just existing processes, policy, and procedures.
To use an analogy, if you had to take a life-saving drug that was developed by a company certified at capability maturity model (CMM) Level 5, compared to a company with only a CMM Level 1 certification, you would go with the company with the Level 5 certification. After all, it gives you the sense of a mature project-based organization, which has its act together. If project management is to take a leading role in a company, it needs to be good in a few areas, which follow:
A project management philosophy is firmly entrenched in the company.
Management has bought into project management as a core competency.
The company is focused on making projects succeed.
The necessary project processes and infrastructure are established.
An effective reporting system is established.
The project methodology and development methodologies are well documented.
Project staff is provided continuous training to update their skills.
Project information is communicated continuously.
Projects are monitored against performance.
Quality and delivery excellence are built into all projects from day one.
Projects are routinely audited for compliance with company standards.
The Capability Maturity Model (CMM)
So what is the buzz all about when it comes to CMM and why should we care? The Software Engineering Institute's (SEI) CMM is not actually a life cycle methodology, but rather sets of strategies for improving the software process on a projects. Therefore, I have not included CMM in Chapter 3. Many companies using CMM are stuck in a default waterfall methodology mentality and have neglected the spiral or iterative development methodologies. This is not CMM's fault at all, but project managers should understand that the waterfall approach is not always the best way to proceed. However, CMM has made advances in covering aspects of iterative methodology projects, although this doesn't always come across as being communicated to the project community. CMM tends to overemphasize inspections, peer reviews, and enforces strict quality assurance (QA) adherence, forcing many projects into paper and meeting "overload," which is also not good.
The primary objective for any company is to achieve a Level 3 CMM certification. Many companies are rated on how well their processes and systems meet the best project standards. In other words, if it does the prescribed set of foundation project activities, it is a Level 2. If it then does a prescribed set of project activities as a "company," it is Level 3, and so on. Essentially designed by SEI to help organizations overcome their problems, the system provides an effective and proven method for gradually gaining control of and improving product development processes, a yardstick against which companies periodically measure their production process, and data with which to prioritize and manage improvement efforts. I have included CMM in this book because many people are convinced that it is a variant of a project methodology, which is untrue. The areas of CMM are: (1) SW-CMM for software, (2) SE-CMM for systems engineering, (3) IPD-CMM for integrated product development, (4) SA for software acquisition, and (5) P-CMM for human resources.
An instrument for assessing a company's current maturity level and project practices is a software capability evaluation (SCE), which determines whether a company "says what it does and does what it says." Therefore, to gauge a company's actual performance, you need to perform an accurate assessment, which is not always done; instead, CMM is applied as both the development and assessment standard. The RUP or ISO 12207 standards are other references.
Together, this set of strategies is being integrated into what is now known as CMM Integration (CMMI). The CMMI is a more activity-based approach, which integrates many of industry's modern best practices and discourages an alignment with the waterfall mentality. Hence, CMMI is more iterative in concept versus the traditional CMM waterfall concept.
CMM describes both unique product development practices and the common management practices that any organization must perform. These practices are organized into five levels, each level describing increasing control and management of the production environment, starting with ad-hoc performance and culminating in controlled, structured, continuous improvement. An evaluation of the organization's practices against the model, called an assessment, determines the level, establishing where the organization stands and which management practices the organization should focus on to see the highest return on investment.
SEI Fellow Watts S. Humphrey created CMM in 1987. CMM is more than 10 years old and has greatly influenced the software industry by having us focus on the development and project process. However, technological shifts are taking place that require development to be more proactive. Originally funded by the U.S. Department of Defense, CMM is used by more than 5,000 government and private companies in more than 42 countries. Large portions of the Level 5 assessments that have been made are based in India. One of its primary goals is to identify and reduce errors during the initial coding process and thereby reduce the amount of rework required from finding errors during testing. The CMM is organized into five maturity levels:
Level 1: Initial. This describes a company with an immature or undefined process. The software process is characterized as ad hoc and, occasionally, even chaotic or unpredictable. Few processes are defined, and success depends on individual effort and heroics.
Level 2: Repeatable. Project management structures and controls begin here. Basic project management processes are established to track cost, schedule, and functionality. The necessary process discipline is in place to repeat earlier successes on projects with similar applications. The key components of project management at this level are: requirements management, software project planning, software project tracking and oversight, software subcontract management, software quality assurance, and software configuration management.
Level 3: Defined. The software process for both management and engineering activities is documented, standardized, and integrated into a standard software process for the organization. All projects use an approved, tailored version of the organization's standard software process for developing and maintaining software. The key process areas at Level 3 address both project and organizational issues. At this level, the company establishes an infrastructure to institutionalize software engineering and management processes across all projects. Compliance with these standards for all projects and by all project managers and development teams is needed.
Level 4: Managed. Detailed measures of the software process and product quality are collected. Both the software process and products are quantitatively understood, controlled, and evaluated by an executive and related staff. The key process areas at Level 4 focus on establishing a quantitative understanding of both the software process and the software work products being built. They are quantitative process management and software quality management. It is at this level that analysis tools such as function point analysis and other performance metrics are implemented.
Level 5: Optimized. Continuous process improvement is enabled by quantitative feedback from the process and from piloting innovative ideas and technologies. The key process areas at Level 5 cover the issues that both the organization and the projects must address to implement continual, measurable software process improvement—defect prevention, technology change management, and process change management.
Getting your company to make an effort to move up the CMM ladder may not be easy. CMM focuses mainly on activities and supporting documents associated with a conventional waterfall process, such as plans, specifications, QA audits, inspections, and formal documented processes and procedures. It's very documentation orientated, and this drive to produce more documents can actually slow a company down. However, this needs to be better addressed by CMM.
Many companies simply do not have the commitment, time, and resources to graduate beyond Level 1 or 2 on the CMM scale. So they stay there. The downside is that these companies eventually lose business, because nobody wants to hire a company who is rated as "ad-hoc" Level 1 on the CMM scale. There are even fewer companies identified at Levels 4 or 5. However, at these levels, you will undoubtedly find that more reviews, inspections, and meetings take place just to satisfy the CMM auditing and certification requirements.
In conclusion, assessing your project management in your company and thereby gauging yourself against others requires that you apply some form of metrics to your projects. CMM/ CMMI techniques are a way to do this, showing you know how your project management measures up to the rest of the industry. It's a clear way to determine if "you're doing what you say you can do."
Using the Mind-Mapping Concept
The one effective way to lay out the envisaged framework of a project methodology is to illustrate or mind map it on paper first, thereby addressing all areas of the organization. Figure 2.4 shows a typical mind-map framework. You can easily start developing a framework in this manner. Look at the way we mentally organize our thoughts—as this is very relevant to thinking about methodologies. If you cannot map out a process, it is futile. However, the human brain is so sophisticated that the mind-mapping method guides the methodology development process. Your brain initially encounters biochemical or electromagnetic resistance along its pathway, where thoughts are reduced. It's like trying to clear a path through a forest. The first time is a struggle, as you have to fight your way through the undergrowth. The second time you travel that way, it is easier because of the clearing you made on the first pass. Frequent repetitive events make it easier for you. Likewise, creating mind maps and documenting them in creative graphical formats assist the human brain in receiving, holding, analyzing output, and control. What happens in your brain when you want to design a project methodology? The answer is both simple and amazingly complex. Every thought or bit of information entering the brain—experiences and memory (template, code, word) can be represented as a central sphere that radiates tens, hundreds, thousands, millions of hooks—which represent associations—that in turn have their own links and connections. The number of associations you have can be thought of as your memory or database. As you read these words, you can be assured that in your brain is an analytical super computer that is far superior to many of the world's most advanced computers. The mind-mapping technique offers us the following approach:
It has a central theme.
It has branches of themes, which radiate from this central core.
These branches contain keywords and are connected.
This together creates a "picture" of the solution or idea you need.
Figure 2.4: Mind-mapping methodology.
A mind-mapping method can be extended easily to designing or conceptualizing any project methodology in existence in a graphical manner. From this, anything is possible.
Key decision makers must often determine whether a universalized project life-cycle methodology is sufficient for all their projects. The answer to that question is an unequivocal no! Very few people are capable of creating a state of-the-art, concisely defined, phenomenally small, highly prescriptive, measurement-intensive, fast, and cost-efficient methodology allowing project managers greater performance improvement (consisting of an expertly designed/optimized family of policies, procedures, plans, specifications, forms, logs, and metrics). Every company has its own process flow diagram. This flow originated from a methodology created to ease implementations of new technologies or new project ideas. These process flow diagrams have many different stages, all similar in nature.
Even dynamic project-based organizations such as Accenture, KPMG, Deloitte Touche, RCG Information Technology, Bechtel, and Keane are far more than a collection of individual projects. If that were all they were, they wouldn't be multimillion-dollar organizations. They all use various arsenals of project methodologies for each solution they undertake. Companies are becoming very much like small film studios. Each project is a "movie" all by itself and has its own "director" and "script." The movie needs project funding to begin and is short lived; project teams are also short lived, and, amazingly, in this brave new model, they follow a unique project methodology, because if they don't, no one will invest in a "movie" or project. Therefore, projects need to be innovative, they need process, and they need to adhere to the "script" or methodology. Each movie script is different from the next; this is where we focus our efforts throughout the book.
By simply assessing those project methodologies that exist today, we see that a universal project approach simply won't work. The main reasons that a single "be-all-and-end-all" methodology won't work from industry to industry are differences in:
Life cycle.
Market sector.
Product.
Size.
Technology.
Situation.
For instance, a nuclear plant or space shuttle project has very specific heavyweight life-cycle components (e.g., work breakdown structure, activities, tasks, task durations, priorities, skill sets, and economics) compared to a small construction project. In other words, they use different phases and activities on their projects (i.e., communications and navigation equipment, operating systems, and a variety of technologies).
In addition, the life cycles for construction projects (e.g., bridge building), compared to information systems projects (e.g., three-tier architectures), may be vastly different from one another. This means much tweaking is needed if you have to accommodate every kind of project. Hence, different methodologies are needed. Therefore, we have a catch-22 situation—various technologies and industries make it very challenging to design a one-size-fits-all project life cycle. It does not seem likely that an individual project manager or executive can actually design a highly operational, functional project methodology that meets the needs of every single project—irrespective of its technology or industry. Hence, some creative genius is needed to bridge this gap. A project life cycle is, therefore, a collection of project phases. Project phases vary by project or industry, but some general phases include:
Concept.
Development.
Implementation.
Support.
Remember that products also have life cycles. Many companies have project managers or executives who are unwilling to follow systematic project methodologies all of the time. Instead, they tend to rely on standard business activities to get them through the project. They are simply trying to keep up with all this talk of project methodologies and associated processes and techniques. Questions such as "Why are there so many methodologies?" and "Which one do we use?" often arise. Over the years, even those involved in managing projects have observed that projects have common characteristics that can be formalized into a structural process, which allows them to manage projects more effectively.
Each phase can typically be brought to closure in some logical way before the next project phase begins; and each phase results in discrete milestones or deliverables, which provide the starting point for the next phase. Project methodologies should be structured to take advantage of the natural phases that occur as work progresses. The phases should be defined in terms of schedule and specific accomplishments. Define how you will know when you have finished each phase and what you will have to show for it.
Cost and schedule estimates, plans, requirements, and specifications should be updated and evaluated at the end of each phase, sometimes before deciding whether to continue with the project. At times, you may want to hold off or cancel the project. Large projects are usually structured to have major program reviews at the conclusion of significant project phases. These decision points in the life of a project are called major milestones. Figure 2.1 shows how project phases are somehow linked to one another. This is the basis of how project phases, once incorporated, form a typical project development methodology.
Figure 2.1: Depiction of general project methodology phases.
Milestone decisions are made after conducting a major program review in which the project manager presents the approved statement of requirements, acquisition strategy, design progress, test results, updated cost and schedule estimates, and risk assessments, together with a request for authorization to proceed to the next phase. The early project phases tend to shape the direction for all further efforts on the project. They provide requirement definitions, evaluation of alternative approaches, assessment of maturity of technologies, review of cost, schedule and staffing estimates, and development of specifications.
A relatively short-term or technically straightforward project may have only a few basic milestones or deliverables following a (1) proposal, (2) feasibility study, or (3) business case. Nevertheless, the project manager should report to clients and executives at intervals to keep them up-to-date on project progress, thus ensuring project direction. (See lightweight methodologies in Chapter 4.)
On small projects, if no formal agreements are written, the project manager should deal with clients and executives in an informal, yet somewhat structured and logical, manner. This means managing expectations and making clear agreements about what will be produced and when. You simply cannot do this on the fly.
On long-term projects, you may find project phases take place over many months or even years, and, in this case, it is vital to provide interim deliverables to give the clients and executives a sense that work is being accomplished, to provide an opportunity for feedback, and to capture project successes in documented form. This is exactly why a project methodology works. How else are you going to do this? (See heavyweight methodologies in Chapter 4.)
It is wise that the project processes be built around the specific project methodology. Particular care should be given to defining the work to be accomplished in each phase. This should include definition of the deliverables to be produced, identifying testing and demonstrations to be completed, preparing updates of cost and schedule estimates, reassessing risks, and conducting formal technical and management reviews.
Background to Project Methodologies
Project management has grown from the early initiatives in the U.S. defense and aerospace sectors in the late 1950s and 1960s. The U.S. Department of Defense and NASA achieved early project management successes—mainly promulgated through their internal policies, procedures, and lessons learned. From this flowed numerous white papers, articles, seminars, and training programs that expanded the project management genre, although much of the theory centered around the use of tools and techniques, such as:
PERT/Gantt charts.
Critical path.
Scheduling techniques.
Organizational issues.
Conflict management and others.
From the early 1970s, project management societies began to provide communication on the discipline, basically through journals, conferences, and seminars. This continued until the mid-1980s when, first, the U.S.-based Project Management Institute (PMI) and, later, the U.K.-based Association for Project Management (APM), embarked on programs to test project management professionalism. This brought about certain guidelines and bodies of knowledge (e.g., PMBOK, APMBOK), which addressed some methodology but did not address every industry and type of methodology. Other organizations developed their own versions of a project methodology.
In the pioneering days of project management, it was common practice for project staff or managers to devise their own methods of moving through the life cycles of their projects, which were often influenced by information technology, engineering challenges, or financial constraints. It was a time when a project was driven by the events that occurred while on the job. This was fine for certain projects, but it led to the failure and delay of many projects because of problems that started to show (1) poor or inconsistent project designs, (2) poor project analysis, and (3) ineffective project communications. It seemed projects lacked the rigor and key ingredients to make them more effective. Sometimes, it takes a complete outsider to show how to expedite projects more quickly than before, in innovative futuristic ways. Look at what BMW has done—you can today log onto their Web site and purchase a customized vehicle, specified by you instead of selecting one from a standard showroom floor model. The production-to-delivery process is drastically reduced and flexible.
A great analogy of the need for appropriate control is found in Formula One racing. Here, the powerful cars have braking systems to enable them to go faster rather than to slow them down. Likewise, in different industries, appropriate levels of control allow an organization to grow and flourish within appropriate boundaries. Both project managers and executives need to understand the impact that new developments in technology are having on business from the project, operational, and risk points of view. It is possible to split the responsibilities of methodologies into three broad areas:
Managing project performance.
Managing the project life cycle.
Managing the resources and communications aspects.
Having the right processes in place to address these areas is a challenge faced by every project manager. I address each of the components of the guidelines because I believe they provide a well-researched and practical solution to this project management challenge.
Everywhere I go, clients ask the same question: "How do our project practices compare with those of our competitors or with those of our peer organizations?" Until now, this information could be obtained only from consultants, market research, or other third-party sources. The project methodology maturity models provide information whereby an organization can carry out a self-certification to grade its own processes from virtually nonexistent to the purist levels, principally as a means of identifying improvements and actions to take.
It is essential that the management of any organization identify and articulate its critical success factors (CSFs). These are the ground rules that determine the appropriateness of the environment in which the organization operates. The CSFs set out the culture, behavior, and actions for management to take to achieve its objectives relating to project methodologies. The guidance provided in the chapter should be easy to apply in practice.
Assessing the Project Methodology Ecosystem
In the context of this book, a project management methodology is considered part of an overall larger ecosystem. The ecosystem can be viewed as a "give and take." Whenever you "touch" the ecosystem, there are things that are bound to occur. Table 2.1 lists what the ecosystem consists of.
Table 2.1: Project management ecosystem components Component
Example
Project standards and best practices
PMBOK, RUP, Java
Supportive processes
Change control
Project management infrastructure
PMO
Templates
Project brief
Performance metrics
ROI, BCA
Project activities
Testing
Project techniques
WBS, Use cases
Project tools
MS project
Project roles and responsibilities
Project teams
Core project methodology framework
PMLC process
Development methodologies toolset
Prince2, XP, Spiral
Figure 2.2 shows the makeup of the project management methodology ecosystem. Remember that any sudden change to the core methodology will result in a change to many other areas, such as templates and a ripple effect on supportive processes. Project managers wanting to deploy any methodology in an organization should realize this natural effect.
Best Practices for Project Methodologies
Most projects share a common life cycle. This is not to say that these projects are all designed and executed the same way, but they remain universal, as they pass similar phases during the life cycle of the project. When dealing with any methodology, ask the following questions:
How do we ensure that our projects develop and deliver successful products? Is the methodology able to accurately capture requirements and effectively manage the project against those requirements?
How can we deploy projects more quickly, avoiding overruns and poor performance, and for better value, lower cost, and better functionality?
When looking at organizational project methodologies available today, we realize that certain methodologies work well and some do not. Some are more proactive than reactive. For those that are not well planned, the organizations will simply not have success with those methodologies. Competitors will overpower them and deliver products faster to the market, and the organization will face competitor lockout. Some of the following best practices are needed before designing, purchasing, or benchmarking a prospective solution:
Provide standard proven processes and techniques.
Benchmark or leverage the best that your industry has to offer.
Create a list of "must-have" components.
Recognize the necessary processes you need to complete projects.
Consider the best cost and time schedules for your methodology.
Determine what core competencies are important.
Configure resources.
Integrate with suppliers and parties.
Understanding Project Life Cycles
After the project life cycle is defined, the project budget and technical aspects must be managed together. And this is important. Can you imagine delivering a project within cost and schedule but that the project does not meet its technical specifications? I think not—a project life cycle must be efficiently managed if the project is to be successful.
An iteration is defined as a distinct sequence of activities with an established plan and evaluation criteria resulting in an executable release. If we examine the set of illustrations describing the waterfall approach, we can see that an iterative approach does have advantages over a straightforward waterfall approach. This analogy should help reveal other ways to manage projects.
On many projects, where dates have been preset either by sales executives or senior corporate stakeholders, project managers often do not have the luxury of changing the fixed end date. Hence, how do you meet a fixed end date? Would a System Development Life Cycle (SDLC) or a Rapid Application Development (RAD) approach work better for you (i.e., incremental versus an iterative approach)?
Delegates attending my project presentations often ask: "How do I make my view of the world work, when working with new technology projects?" "What methodology do I follow?" I always respond by stating that you have control over only the inputs you receive, and you define your projects based on those constraints. It's not up to you to start reorganizing the organization just for your project. First, see what's within your boundaries. Then act from there.
CIPOC—A Conceptual Approach
When I try to place any project life cycle or methodology into perspective, I always go back to the Client, Input, Process, Output, Clients (CIPOC) approach, a slight deviation from the "supplier" concept. It is one of the greatest examples of a primer that gives a high-level conceptual view of the way all project methodologies fit into the grand scheme of things (see Figure 2.3).
Figure 2.3: CIPOC technique to reflect methodology usage.
CIPOC works like this. A client has certain requirements for which he or she needs a certain solution. This can be a new skyscraper, submarine, spacecraft, software, or even a rock concert. It doesn't matter what kind of project. These client requirements are formed into inputs, which in turn serve as the defining moments or starting point for the process—which can be virtually any methodology you want to use (e.g., Waterfall, SDLC, PACE, RUP, XP, MIL-STD-1612, PRINCE2). The project manager uses his or her chosen methodology and proceeds to design, build, test, and deploy the solution. These are the control points. When complete, an output has been generated that is then accepted by the client. The client can be involved anywhere in the CIPOC approach; the client readily provides feedback at any stage.
All assumptions must be made upfront at the onset of the project process start. This is one of the control points. If the project manager cannot control the assumptions, the project may come back and bite, irrespective of methodology employed.
If you need 500,000 kilowatts of power in a remote location, how do you do it? How do you meet your client's needs? You need an approach, and, typically, you would follow a CIPOC approach. Similarly, the Winter Olympics held in Salt Lake City was a phenomenal project itself. The Olympics organizers, too, would follow the CIPOC approach.
If we examine major companies such as Ernst & Young, RCG Information Technology, and IBM, we find that these major solutions companies have total "soup-to-nuts" project methodologies in place. These project methodologies embrace everything from the initial sales call, defining the solution, right through to deployment. They can identify the appropriate resources needed per project life-cycle phase (i.e., account executive, recruiter, designer, tester, project lead). These methodologies are well documented. If we examine other companies (e.g., home builders, software developers), we find that many don't have the luxury of such an elaborate project methodology in place. They simply adhere to projects in their own informal manner.
Understanding Project Model Terminology
Project Feasibility and Justification
The project manager's first task is to become familiar with the feasibility of the project. He or she should reaffirm to his or her own satisfaction the findings of the original study, which may have been some time ago, certainly before he or she accepted the job. Thus, reaffirming the feasibility and justification of the project is crucial.
User Requirements
The most important phase in any project is to find out what is actually needed. Without proper establishment of the requirements, no one is certain what is really required. This is not covered fully in the Project Service Request (PSR); therefore, work and effort are needed at the start of the project. Subsequent time may be wasted if the user requirements are not established and understood.
System Design
After establishing and agreeing on the requirements, a high-level design of the main functions of the system can be produced. This is followed by considering the development of each of these main functions in more detail.
Detailed Design and Buy or Build
These follow the established meanings found in most development models. Each activity in the work breakdown structure (WBS) is given sufficient individual attention so that it is designed in detail ready for building. These phases apply equally to the design and creation of documentation as well as software. They also apply to hardware, except that items needed to run the software will be ordered from suppliers instead of building the items. The hardware design is determined by the software requirements.
Acceptance
The acceptance phase is the running of integration tests at system level to prove all documentation, software, hardware, and other equipment. These tests must be designed carefully and not left to the suppliers (of equipment, software, and documentation) to construct. Otherwise, we find that suppliers may test only the parts that work and may deliberately not consider the whole system, which may lead to problems for the end users. Notice that testing occurs throughout the project—not delayed until a single testing phase when and where it would be too late to rectify faults efficiently. This phase is about testing to accept the whole system, not testing to see if it works.
Commissioning
Every component is built, tested and integrated. Commissioning is the setting to work of the proven and integrated system. This is the time to introduce the end users to their relevant parts of the working system and then cut over to the live system. During this stage (or even before in some projects), user training takes place and the help desk is set up.
Completion and Post-Implementation Audit
When all stages are completed to the satisfaction and agreement of all parties, it is important that the project be recognized as complete. At this stage, it is crucial that the project manager document the following before starting another project:
Job descriptions for operations staff.
Job descriptions for systems staff.
Working practices for operations and systems teams agreed on by management, operations manager, and systems manager.
Rolling plan for update, upgrade, and replacement of equipment over the next two to five years.
A plan to ensure that all documentation is complete and signed off.
A plan to ensure that all contractors, subcontractors, and self are paid up-to-date.
A postimplementation audit date for three to six months after project close-down.
In the postimplementation audit (PIA), the project manager returns a few months after responsibility for the new system has been assumed by the client (i.e., steady—state). The actual audit procedures should be determined initially, indicating that a team will return to see whether the system is working as designed. Most of this audit consists of ensuring that the project team is adhering to established working practices. It is quite surprising how people misinterpret documented procedures and invent ways around problems. These issues of documentation standards are beyond the scope of this book. The PIA has rarely been carried out in the past and is only now gaining a reputation for its usefulness.
Roles and Responsibilities on a Project Life Cycle
Table 2.2 reveals typical roles and responsibilities that one would encounter on a project. The larger the project, the more roles and responsibilities would be added.
Table 2.2: Roles and responsibilities on the project life cycle Roles
Responsibility
Verify resource allocation
Project Manager
Assign individual responsibilities
Project Manager
Verify project scope and change control
Project Manager
Estimate work packages and time to complete project
Project Manager
Monitor and control life cycles
Project Manager
Reduce uncertainty
Project Manager
Improve decision-making process
Sponsor
Attain effective solution
PM/Analysts
Establish continuous improvements to project
PM/QA
Maintain focus of project goals and objectives
Sponsor/PM
Provide continuous feedback to executives and stakeholders
Project Manager
Manage project plan
Project Manager
Avoid possible risks and issues
Project Manager
Maintain focus of schedules, budgets, and work plans
Sponsor
Likes and Dislikes of Project Methodologies
Often, one person may give a project manager the best kudos and praise for adopting a certain project methodology, but too often, the kudos arise mainly from the ranks of the management layer. Methodologies are like an onion—just when you peel off one layer, you discover another layer waiting for you. Some of the pros and cons seen by managers and nonmanagers working on projects are listed in Table 2.3.
Table 2.3: What managers and nonmanagers think of methodologies Project Managers Think
Nonmanagers (Team Members) Think
Methodologies define a set of deliverables.
Methodologies do not really represent what actually happens.
Methodologies adhere to a structured approach.
Phases are often overlapping with other phases.
Methodologies bring structure to a chaotic environment.
Methodologies are a waste of time and unnecessary overhead.
This is the way companies should be run.
No one clearly knows the true value of this path.
Methodologies don't always reflect the technical requirements.
Blueprints for Business Innovation
Because the introduction of a project management methodology and its processes possibly needs to be integrated into the existing business processes, it becomes necessary to stop to look at what we need to take care of before simply designing a methodology. Business process reengineering focuses on optimizing existing processes and facilitates the redesign of these processes if they are outdated and superfluous to departments or units, they do not meet clients' needs, or they are causing long delays for meeting organizational strategy.
Look at how Dell Computers is able to reconfigure its production lines for flexible, more rapid market demands. They adapt more quickly than their competitors and apply great methodologies for their solutions. Look at how Walt Disney has moved beyond the realm of its theme parks by having its own line of cruise ships and entertainment—all innovative by design—reflecting that Disney is able to transcend the norm.
In Table 2.4, note that in any organization today, there are existing processes that directly interface with the aims and objectives of what many project managers are trying to do throughout the course of a project's life cycle. Remember that project management is about managing the triple constraints, which are (1) cost, (2) time, and (3) quality. It's not that simple for project or development managers to simply ignore existing processes to get their jobs done. The methodology should be tightly and seamlessly integrated into the existing processes, so much that they complement one another.
Table 2.4: Examples of processes in organizations Process
Function
Affects Project Management
Invoicing and posting of credits
Financial
ü
Purchasing of goods and services
Procurement
ü
Timesheet submission
Financial
ü
Financial monthly reporting
Financial
ü
Salaries
Financial
ü
Legal disputes and claims
Legal Council
ü
Recruitment of staff
Personnel
ü
Strategic prioritization of projects
Projects
ü
Quality control and assurance
QA
ü
Training
Training
ü
Profitability
Financial
ü
Methodology Design
The focus of this section is how project methodologies can be developed to support projects in a company. Developing a project methodology and adapting it to the situation often deal with changes on many levels—changes in culture, processes, and information systems. A culture can provide project teams with a shared frame of reference and facilitate communication. The processes can provide a structure of activities in the projects, which helps new employees and can provide a common language. Information systems may be linked to the process and provide the tools that influence the daily work.
The research is based on active participation during the development of a methodology for product development. The case illustrates the tendency to focus on the process level and underestimate the importance of influencing the culture and adapting the current system to the new envisaged processes. The results are analyzed to provide increased understanding of the success factors when new project methodology is to be developed. The aim is to create a framework that can be used by companies that want to develop a project methodology or improve their existing project methodology.
With any new process, the way an organization works—and its entire culture—changes. Hence, it becomes crucial that the project manager not only develop the project management processes themselves but also create:
Support plans.
Communications plans.
Deployment plans.
These elements facilitate cultural change in a company and are fundamental to a successful project management deployment. You should not "reinvent the wheel" for each client engagement. Tailor project management processes that best suit your needs. The project manager should understand business processes and be able to merge them with current and tested best practices to quickly and effectively produce a tailored, client-specific set of project processes. It's not easy—developing processes is a science in itself. The question is: Do you have time to implement these processes on your own? Or, is your time running out? How much help is needed to design these processes to support your project framework?
Project Methodologies Demystified
We now examine the relationship between methodology size, project size, and problem size. This discussion can be tricky because there is a tendency to think that more people must solve larger problems.
Project size and methodology are connected by a positive feedback loop. With relatively few people, relatively little methodology is needed. With less "weight," they work more productively. With greater productivity, they can address a larger problem with their smaller team and lighter methodology. On the other hand, when more people are assigned to a project, they need more coordination (i.e., more methodology). The heavier methodology lowers their productivity; therefore, more people are needed to accomplish the same work. Methodology grows more slowly than project size, so eventually they get to a point where they can solve the problem and manage the coordination activities (assuming sensible management).
Therefore, for a given problem, you need fewer people if you use a lighter methodology and more people if you use a heavier methodology. However, there is a limit to the size of problem that can be solved with a given number of people, and that limit is higher for a large team using a heavier methodology than for a small team using a lighter methodology (i.e., at some point, you will need both a large team and a heavier methodology). The difficulty is that there is no reliable way to determine the problem size at the start of a project and no way to know the minimum number of people needed to solve it. The number of people varies with the people in question. Finally, as the project grows in size, a different combination of methodology and project size becomes optimal.
To begin to consider what constitutes a good and effective project management or development methodology, you need to clearly understand what phases are available to use, within all the project and development methodologies that face you as a project manager. The most common phases you would likely encounter when discussing or designing a methodology are discussed in the following sections.
Discovery/Concept/Idea
A well-conceived idea is the creative stuff that makes everything important. It's why the project started in the first place. There is no launch if there is no acceptable initial idea. Brainstorming is an effective technique to help you develop a prime idea. Be aware of the effect that the external environment (customers, competitors, market, etc.) has on the idea. In the concept stage, the exact definition of the idea and strategy is derived. The objective is to develop a protocol with defined target markets, product concepts, and attributes.
Engagement/Concept
Because each project is unique and must be approached very differently from the next because of client requirements and demands, in the engagement or concept phase, the project manager and sales executive actually meet with the client and discuss possibilities and begin to extend the communications process between the parties involved. This is often the most important phase as it sets the standard going forward. This can initially be a single occurrence or a series of meetings that brings the stakeholders together. It identifies key role players in the project and starts setting responsibilities.
Analysis/Feasibility
The analysis or feasibility phase determines that the project has been thoroughly assessed and deemed economically or strategically feasible to continue. If the analysis weighs against the project's success, the project is discontinued or returned to executives for further discussions. It is highly recommended that projects be analyzed before commencing to the next phase of the project life cycle or methodology.
Strategy Planning
Every company needs to have a system for deciding on and formulating the necessity and priority of launching any project or product. Whether a new design or new release of software, the strategists need to plan within the framework of the business model. The strategy planning would allow decisions about launching additional projects to support a priority project or delaying certain projects to favor a more important project's getting to market.
Feasibility Assessment
Before committing time and resources to any development, it may be necessary to establish the need for the project. Sometimes, it's not feasible to commit the organization to even attempt the project because it simply duplicates another effort or costs too much to gain a successful foothold in the marketplace. Additionally, the technical feasibility of the project may be unknown, and without performing a proper feasibility study of the technology, the project would result in negative cost and schedule delays.
System Analysis
After the project is launched, it becomes vitally important to establish client requirements to start designing the eventual system or product. At this stage, the project team should use techniques to fully understand what the project should deliver.
Design/Development
On any project methodology, one of the key phases is the design or development phase. The phase represents the solution build. Key staff—such as designers, architects, or engineers—develop a solution based on either partial or full user requirements. This design will form the basic building blocks from which the project team will work.
Deployment/Execution
After the project has been built, tested, and proven to work as designed and specified, the project is ready for installation or rollout. It is during this phase that the product or system is finally assembled and installed. In addition to simply implementing a system, users must be trained.
Testing
This phase indicates the formal testing of the solution. Testing can be done either incrementally or at the end of a development phase if following a waterfall approach.
Quality Assurance
In the quality assurance phase, the solution is validated and tested against the initial specifications of the project.
Training/Education
Before any system or project is fully deployed, users need to be identified and trained. This phase may involve establishing the training requirements for the project and generating either the necessary training courses or documentation.
Rollout/Implementation/Deployment
This phase is the delivery of the solution within the client organization. The rollout takes effect when the system is ready to be installed either in a series of small increments or as a fullblown deployment. During this phase, it is crucial to have an implementation plan and schedule to assist with the details of rolling out the project to the client.
Maintenance/Support/Operations
After the project has been finalized and the product launched, it is considered operational or in production. Therefore, the product must now be maintained. Many products need constant updates or changes. For example, after a new software is launched, it is likely that some updates will be needed. Therefore, the project needs to address exactly how postproject changes will be handled and executed. Considerations such as how incremental changes will be implemented must be resolved. On many other projects, fulfillment and restocking of vital spare parts—including the vendors' support—are crucial in making this project a success. (Methodology support is discussed in Chapter 6.) In this phase, the organization or client introduces operational support for the project once completed. Tasks such as arranging help desk support, service level agreements, and monitoring and diagnostics are performed in this phase.
The Importance of it Methodologies
As many industries use information technology and focus on the development of software, it is appropriate to describe the IT environment to explain why different methodologies are needed for different things. For example, many construction companies that use the standard waterfall methodology are today using IT methodologies—such as RAD—to bring in their predictive and "heavy" schedules more quickly than before. And it appears to be working successfully.
With almost all IT projects today, we typically encounter any one of the following scenarios in which we need to adopt a development methodology. An IT project may consist of three core tiers:
Graphics User Interface tier (front-end). Usually done by visual development languages using tools such as Visual Studio.NET, Java.
Application middle tier. Usually addressed by a business-centric methodology.
Database tier (back-end). Usually accessing one or many databases to retrieve data or information, using tools such as SQL, Java, or object components.
The same development cannot be used for each tier. For example, you are tasked with an IT project in which you have to use only the top layer—the front-end—then you need to consider your specific development options. They may be application specific. The same applies for the other two tiers.
Identifying Your Project Maturity
Many companies are very aware of the important role project management plays in their companies, but many are somehow unable or unwilling to make a transition to develop their project philosophy to the next level. Companies want to know exactly (1) how well they are currently doing and (2) where they would like to be on a project maturity level. After all, a company is more than just existing processes, policy, and procedures.
To use an analogy, if you had to take a life-saving drug that was developed by a company certified at capability maturity model (CMM) Level 5, compared to a company with only a CMM Level 1 certification, you would go with the company with the Level 5 certification. After all, it gives you the sense of a mature project-based organization, which has its act together. If project management is to take a leading role in a company, it needs to be good in a few areas, which follow:
A project management philosophy is firmly entrenched in the company.
Management has bought into project management as a core competency.
The company is focused on making projects succeed.
The necessary project processes and infrastructure are established.
An effective reporting system is established.
The project methodology and development methodologies are well documented.
Project staff is provided continuous training to update their skills.
Project information is communicated continuously.
Projects are monitored against performance.
Quality and delivery excellence are built into all projects from day one.
Projects are routinely audited for compliance with company standards.
The Capability Maturity Model (CMM)
So what is the buzz all about when it comes to CMM and why should we care? The Software Engineering Institute's (SEI) CMM is not actually a life cycle methodology, but rather sets of strategies for improving the software process on a projects. Therefore, I have not included CMM in Chapter 3. Many companies using CMM are stuck in a default waterfall methodology mentality and have neglected the spiral or iterative development methodologies. This is not CMM's fault at all, but project managers should understand that the waterfall approach is not always the best way to proceed. However, CMM has made advances in covering aspects of iterative methodology projects, although this doesn't always come across as being communicated to the project community. CMM tends to overemphasize inspections, peer reviews, and enforces strict quality assurance (QA) adherence, forcing many projects into paper and meeting "overload," which is also not good.
The primary objective for any company is to achieve a Level 3 CMM certification. Many companies are rated on how well their processes and systems meet the best project standards. In other words, if it does the prescribed set of foundation project activities, it is a Level 2. If it then does a prescribed set of project activities as a "company," it is Level 3, and so on. Essentially designed by SEI to help organizations overcome their problems, the system provides an effective and proven method for gradually gaining control of and improving product development processes, a yardstick against which companies periodically measure their production process, and data with which to prioritize and manage improvement efforts. I have included CMM in this book because many people are convinced that it is a variant of a project methodology, which is untrue. The areas of CMM are: (1) SW-CMM for software, (2) SE-CMM for systems engineering, (3) IPD-CMM for integrated product development, (4) SA for software acquisition, and (5) P-CMM for human resources.
An instrument for assessing a company's current maturity level and project practices is a software capability evaluation (SCE), which determines whether a company "says what it does and does what it says." Therefore, to gauge a company's actual performance, you need to perform an accurate assessment, which is not always done; instead, CMM is applied as both the development and assessment standard. The RUP or ISO 12207 standards are other references.
Together, this set of strategies is being integrated into what is now known as CMM Integration (CMMI). The CMMI is a more activity-based approach, which integrates many of industry's modern best practices and discourages an alignment with the waterfall mentality. Hence, CMMI is more iterative in concept versus the traditional CMM waterfall concept.
CMM describes both unique product development practices and the common management practices that any organization must perform. These practices are organized into five levels, each level describing increasing control and management of the production environment, starting with ad-hoc performance and culminating in controlled, structured, continuous improvement. An evaluation of the organization's practices against the model, called an assessment, determines the level, establishing where the organization stands and which management practices the organization should focus on to see the highest return on investment.
SEI Fellow Watts S. Humphrey created CMM in 1987. CMM is more than 10 years old and has greatly influenced the software industry by having us focus on the development and project process. However, technological shifts are taking place that require development to be more proactive. Originally funded by the U.S. Department of Defense, CMM is used by more than 5,000 government and private companies in more than 42 countries. Large portions of the Level 5 assessments that have been made are based in India. One of its primary goals is to identify and reduce errors during the initial coding process and thereby reduce the amount of rework required from finding errors during testing. The CMM is organized into five maturity levels:
Level 1: Initial. This describes a company with an immature or undefined process. The software process is characterized as ad hoc and, occasionally, even chaotic or unpredictable. Few processes are defined, and success depends on individual effort and heroics.
Level 2: Repeatable. Project management structures and controls begin here. Basic project management processes are established to track cost, schedule, and functionality. The necessary process discipline is in place to repeat earlier successes on projects with similar applications. The key components of project management at this level are: requirements management, software project planning, software project tracking and oversight, software subcontract management, software quality assurance, and software configuration management.
Level 3: Defined. The software process for both management and engineering activities is documented, standardized, and integrated into a standard software process for the organization. All projects use an approved, tailored version of the organization's standard software process for developing and maintaining software. The key process areas at Level 3 address both project and organizational issues. At this level, the company establishes an infrastructure to institutionalize software engineering and management processes across all projects. Compliance with these standards for all projects and by all project managers and development teams is needed.
Level 4: Managed. Detailed measures of the software process and product quality are collected. Both the software process and products are quantitatively understood, controlled, and evaluated by an executive and related staff. The key process areas at Level 4 focus on establishing a quantitative understanding of both the software process and the software work products being built. They are quantitative process management and software quality management. It is at this level that analysis tools such as function point analysis and other performance metrics are implemented.
Level 5: Optimized. Continuous process improvement is enabled by quantitative feedback from the process and from piloting innovative ideas and technologies. The key process areas at Level 5 cover the issues that both the organization and the projects must address to implement continual, measurable software process improvement—defect prevention, technology change management, and process change management.
Getting your company to make an effort to move up the CMM ladder may not be easy. CMM focuses mainly on activities and supporting documents associated with a conventional waterfall process, such as plans, specifications, QA audits, inspections, and formal documented processes and procedures. It's very documentation orientated, and this drive to produce more documents can actually slow a company down. However, this needs to be better addressed by CMM.
Many companies simply do not have the commitment, time, and resources to graduate beyond Level 1 or 2 on the CMM scale. So they stay there. The downside is that these companies eventually lose business, because nobody wants to hire a company who is rated as "ad-hoc" Level 1 on the CMM scale. There are even fewer companies identified at Levels 4 or 5. However, at these levels, you will undoubtedly find that more reviews, inspections, and meetings take place just to satisfy the CMM auditing and certification requirements.
In conclusion, assessing your project management in your company and thereby gauging yourself against others requires that you apply some form of metrics to your projects. CMM/ CMMI techniques are a way to do this, showing you know how your project management measures up to the rest of the industry. It's a clear way to determine if "you're doing what you say you can do."
Using the Mind-Mapping Concept
The one effective way to lay out the envisaged framework of a project methodology is to illustrate or mind map it on paper first, thereby addressing all areas of the organization. Figure 2.4 shows a typical mind-map framework. You can easily start developing a framework in this manner. Look at the way we mentally organize our thoughts—as this is very relevant to thinking about methodologies. If you cannot map out a process, it is futile. However, the human brain is so sophisticated that the mind-mapping method guides the methodology development process. Your brain initially encounters biochemical or electromagnetic resistance along its pathway, where thoughts are reduced. It's like trying to clear a path through a forest. The first time is a struggle, as you have to fight your way through the undergrowth. The second time you travel that way, it is easier because of the clearing you made on the first pass. Frequent repetitive events make it easier for you. Likewise, creating mind maps and documenting them in creative graphical formats assist the human brain in receiving, holding, analyzing output, and control. What happens in your brain when you want to design a project methodology? The answer is both simple and amazingly complex. Every thought or bit of information entering the brain—experiences and memory (template, code, word) can be represented as a central sphere that radiates tens, hundreds, thousands, millions of hooks—which represent associations—that in turn have their own links and connections. The number of associations you have can be thought of as your memory or database. As you read these words, you can be assured that in your brain is an analytical super computer that is far superior to many of the world's most advanced computers. The mind-mapping technique offers us the following approach:
It has a central theme.
It has branches of themes, which radiate from this central core.
These branches contain keywords and are connected.
This together creates a "picture" of the solution or idea you need.
Figure 2.4: Mind-mapping methodology.
A mind-mapping method can be extended easily to designing or conceptualizing any project methodology in existence in a graphical manner. From this, anything is possible.
Subscribe to:
Posts (Atom)