Author: Eric Verzuh
Eric Verzuh, PMP, earned his PMP in 1992. He is the author of the bestselling Fast Forward MBA in Project Management and the PMP® Deep Dive, a better, faster, and more fun exam prep program. You can contact Eric via email at EVerzuh@VersatileCompany.com.
Solving the Information Technology Project Puzzle
What is it about information technology projects? Since Gartner highlighted project management as a critical success factor for information technology (IT) projects in ’95, we’ve seen a flood of training, methodology, and PMO initiatives that continue today. Despite this massive investment in better project management, IT projects are a continued source of frustration for many organizations. It’s easy for a bystander to throw stones, so I’ll start by saying that things are a lot better in most IT organizations that they were in ’95. But it’s also undeniable that IT projects continue to have a rocky record. Like most puzzles, the better we understand the source of the problem, the closer well be to solving it. So let’s examine four dimensions of the IT project puzzle, which will lead us to some of the current best practices in IT project management. IT Projects Change Business Processes. Information technology projects support business goals and frequently change the way people within the organization work. So nearly every IT project includes an element of redefining what work is done, as well as the way it is done. Business process change adds an entire new category of risk. There Is an Endless Demand for IT Projects. Few significant organizational changes are accomplished without an IT dimension. Continuously improving technology creates continuous opportunities for improving productivity and innovating products or services. That contributes to failure by overloading personnel and by taking on the wrong projects. Technology Expertise Ages Quickly. As the capabilities of new technologies continue to grow, our expertise for implementing and supporting the technology must grow, too. It makes sense that a risk factor for IT projects is that we find them difficult to estimate. How can we forecast the time and effort well require when we are still learning the technology? IT Projects Include Interfaces. As if applying new technology to newly invented business processes isn’t trouble enough, chances are pretty high that the project will include interfaces to one or more existing systems. Interfaces increase complexity and therefore scope. Scope for IT systems can also include hardware and operating systems factors that may not be apparent during initial analysis. Notice that addressing these challenges push us outside the boundaries of pure project management. They defy any ‘silver bullet’ methodology or software. Yet understanding these four challenges makes it easier to see the source of what have become proven best practices in IT organizations. Here are six practices you should be looking for in your IT organization. Focus on Solving Business Problems, Not Deploying Technology. This principle has been present since the first business system was deployed, and it is the drive behind the re-emergence of business analysts as key contributors on our team. Disciplined Project Management, Particularly Risk Management. The good news is that many teams rigorously practice proven project management techniques. Given the risks associated with changing processes and new technology, risk management takes on a greater role. Set Realistic Baselines Using Phased Estimates. Baselining a project too early is a guarantee the schedule and budget won’t be met. Phased estimating provides a realistic approach to balancing the need for cost and schedule targets with the reality of discovery that exists on many IT projects. A Project Management Office Promotes the Discipline and Coordinates the Projects. Disciplined project management does not occur naturally. It is a conscious choice that requires commitment and encouragement. It is even more effective when the mechanics of project management are practiced consistently from one project to the next. The PMO also keeps an eye on the coordination that needs to happen among projects. Project Portfolio Management Maintains a Realistic and Strategically Aligned Workload. Project Portfolio Management is the process for engaging customers and the IT management team to prioritize projects and to draw the line on how many projects are too many. Choose an Appropriate Development Approach. The rise of Agile software development techniques is a response to the element of discovery that exists in many IT projects. Some projects will benefit from an Agile approach, others will benefit from a waterfall or other more traditional approach. Projects are not all the same. Understand the distinctions between these methods and choose the one that fits the project. IT projects rarely have an auto-pilot switch. They take skill and attention to guide effectively. Recognizing the four challenges described here is the first step in solving the IT project puzzle.
Where To Focus First When Adopting Agile
If you are new to agile and want to understand what all the buzz is about, start by separating agile project management techniques from agile software development methods. Why the distinction? We’ve always had to think about how we manage work separately from how we actually perform the work. To really understand agile, start with the nature of the work. For example, listen to Alan Shalloway, whose firm provides training and consulting to software development organizations and who has several influential books on the subject of agile techniques. To describe agile, Alan lists the five key questions that agile attempts to answer: How do we deliver value quickly to our customers? How do we discover as early as possible what is needed? How can we accelerate the learning of the development team? How can we ensure that the software written will be able to grow and be extended effectively when new requirements are introduced? How do we accurately gauge the progress we’re making in our project? Notice that only the last question is related to project management. The other questions are about requirements analysis and product design. That suggests that organizations who are adopting agile methods should look beyond the typical Scrum techniques (project management) and make sure that developers understand agile analysis, design, and development methods. As Alan’s questions indicate, this is a highly iterative, discovery oriented methodology. To make it work, you need to know how to design and build products that can be delivered incrementally. Classic examples of project management that include pouring a house’s concrete foundation before raising the walls makes the point that certain activities must precede other activities. But these examples also are rooted in linear development methods. Software might lend itself to incremental delivery, but if you try to deliver a house incrementally, one room at a time, it wouldn’t be pretty. And it probably wouldn’t be cheap. Which brings us back to the real agile success factors: design and development techniques. If the essence of agile is to rapidly deliver incremental value, then we have to be able to design and deliver the product, never knowing for sure which incremental delivery will be the last. I have no problem with sprints, daily stand-ups, burn-down charts, etc., but they only make sense in the context of agile development practices. To get a sense of how differently we need to think about building software, consider the example of a car designed with interchangeable parts. You’ve got to see it to believe it. Watch a short video. Now THAT is new. So if your organization has an agile interest, focus first on the fundamental development methods. With those under your belt, Scrum becomes intuitive and the project management pieces fall in place. Further reading: Read Alan Shalloway’s complete description of agile in Chapter 17 of The Fast Forward MBA in Project Management, 4th Edition or visit Eric Verzuh’s Power Blog.
Insights for Scheduling
Finish-to-Start Relationships The finish-to-start relationship states that one task must be completed before its successor task can begin. The network diagrams in this chapter all follow this simple assumption because it is the most common, but there are other types of relationships. Tasks with start-to-start (SS) relationships allow the successor task to begin when the predecessor task begins. Finish-to-finish (FF) tasks can start independently of each other, but the successor cannot finish until the predecessor finishes. The figures below show the value of using these other types of relationships. Finish-to-start: The most common task relationships on the network are finish-to-start. The first task must finish before the next one can start. Start-to-start: The successor task can start as soon as the predecessor task starts. The example shows a painting company, painting all the rooms on one floor of an office building. After the first room is prepared, both the prep crew and the paint crew can begin working at the same time. Overlapping the tasks reduces the total duration of the project. Finish-to-finish: The successor task can finish only when the predecessor task is finished. The example shows the last two tasks of a design phase. Planning for the construction phase can begin before the final design approval, but it cannot finish until the design is complete. Understanding Float Almost every critical path schedule has float. There are actually four kinds of float that can occur in a schedule. Total float = Late start minus early start (LS-ES). Free float = Float that doesn’t affect subsequent activities. Independent float = Free float that cant be used by earlier activities. Shared float = Float that belongs to a path, rather than a single task. This article is excerpted from the new book, The Fast Forward MBA in Project Management, 4th Edition. Copyright 2011. This material is used by permission of John Wiley & Sons, Inc.
Three Common Principles for Project Initiation
The biggest decision in the life of a project is the original commitment to pursue the project. It sets the goal and begins a series of events that could last for years. It makes sense that initiating a new project should be based upon careful, thorough analysis. But with so many kinds of projects out there, are there really any universal rules? For example, will the U.S. Army consider replacing the Humvee personnel carrier using the same process that a marketing department uses to analyze the addition of a CRM system? Does a real estate developer research the feasibility of a new shopping mall the same way a bricks-and-mortar retail store owner evaluates the move into e-commerce? Clearly these are all quite different types of potential projects, and the proper analysis for each one varies. The most complex products require the most sophisticated and time-consuming evaluation. The U.S. Army and major real estate developers have sophisticated procedures and legions of professionals trained to perform rigorous analysis. That just isn’t possible or appropriate in many organizations. But that doesn’t mean every project can’t apply some commonly accepted best practices before plunging into a project. The wise organization is able to extrapolate from the best practices that follow and match them to their organization. 1. Involve a Wide Variety of Stakeholders Knowing who is involved or affected by the project is critical to effective project execution. It may be more important and more difficult during project initiation — more important because this is the time we set the goals and direction of the project, and more difficult because there will be a much broader group of potential stakeholders during this early analysis. Use the following perspectives as a guide for your own efforts to include and engage the right stakeholders. Understand the problem or opportunity from the perspective of everyone it will affect. Using the example of the U.S. Army’s new vehicle, that includes maintenance and manufacturing as well as the soldiers using it in the field. Imagine all the people who will touch the product during the full product life cycle. What are their concerns or desires related to the problem or opportunity? There may be advocates for change and advocates for maintaining the current state. Why? What stake does each have in making (or not making) a change? Dr. Robert Cooper with the Product Development Institute is the leading authority on managing new product development. Among the primary factors that distinguish successful new products from failures, he cites voice of the customer and competitive analysis. Voice of the customer means actively engaging with potential customers to understand the way they perceive a product or problem. Competitors are also stakeholders. Do you know what they think about this issue? Federal, state, and local government agencies are full of stakeholders. Laws and regulations form constraints to the situation. Zoning laws, for example, restrict the use of real estate, governing what types of buildings and activities are allowed. Integration with existing systems is an issue on all kinds of projects. An e-commerce website will integrate with a secured payment processor. A military fighter jet that needs to refuel on the fly must consider the tanker aircraft that provides the fuel. A new mobile phone app must work with the phone’s operating system. Stakeholders have values, beliefs, and habits that form their culture. Their enthusiasm or resistance to a change may be a deeply emotional response. Dr. Atul Gawande participated in a campaign to introduce a simple pre-surgery checklist into operating rooms and found that the hierarchical relationships between doctors and nurses created a major obstacle to adoption. Viewed from this perspective, it might seem that there is a never-ending list of stakeholders and that seeking them all out will take an eternity. That is not the intention. However, it reinforces that the analysis performed to build a project proposal is not trivial and often requires specialized skills and knowledge. The bottom line is that listening to stakeholders will surface requirements and constraints. The earlier these are exposed, the cheaper they are to manage. 2. Clarify the Problem Before Proposing a Solution It seems pretty obvious that we should agree on what problem is being solved before coming up with great ideas to solve it, but not doing this is a classic mistake. Failure to clarify the problem is a common source of disappointment, particularly because it is routinely discovered after the project is complete. Call it human nature. Reinforce it by applauding it as being decisive and action oriented. Do it because that’s what the customer asks for. But taking action without clarifying the problem will always be a mistake. Every sound product-development or problem-solving approach shares this principle. Define the problem as the gap between the current state and the ideal state, often literally referred to as gap analysis. The ideal state should not include a specific solution, but rather the capability we want but don’t have. Describe the primary success criteria in terms of what the organization or customer will be able to do as a result of the project’s successful completion. Many completed projects are a disappointment to the customer because they don’t really address the core business or functional need that the customer had. It takes skill to uncover and document enterprise requirements, because they usually lurk beneath the surface — below the symptoms of the problem or the customer’s perception of what solution should be implemented. Remember that these requirements will be elaborated on during subsequent phases of the project. By disciplining ourselves to focus on defining the problem, we expand the range of possible solutions. We are able to get beyond the initial solution that seems so obvious and explore all the possible ways to achieve our goal. Further, the “ideal state” requirements provide the framework for evaluating the possible alternatives. 3. Quantify the Benefits and Costs of the Alternatives This practice assumes that multiple options are being evaluated. Maybe it goes without saying that when we analyze a problem or opportunity, we need to generate several options, rather than just pursue the first one that bubbles up. That is certainly the only way that truly new ideas are created. For each of the many possible approaches that have been proposed, rank them against the enterprise requirements and quantify their benefits and costs as much as possible. Quantifying the benefits will demonstrate how the alternatives vary in their results. Quantifying the costs will provide a foundation for a financial analysis, such as return on investment (ROI). Since most alternatives analysis requires us to compare apples and oranges (options that have different advantages and disadvantages), finding ways to quantify the costs and benefits will allow us to see why we might want to pursue a lower-cost option that produces a lesser result. Or it could justify making the big investment with the big payoff. This article is excerpted from the new book, The Fast Forward MBA in Project Management, 4th Edition. Copyright 2011. This material is used by permission of John Wiley & Sons, Inc.
Using Project Management for Social Change
“Let’s not try to solve world hunger” is an oft-used warning about scope creep. Don’t tell World Vision, Oxfam, Inter-America Development Bank, CARE, Catholic Relief Services, and the hundreds of other nongovernmental organizations (NGOs) working around the globe in developing countries to improve living conditions. Their efforts promote education and increase access to basic health care, clean drinking water, cheap solar energy, and other essentials that citizens of the developed world take for granted. For those of us in the project management profession, it is easy to see this work as a never-ending series of projects. Key people in the NGO community have come to the same conclusion. Their passion for project management and development has created PM4NGOs. PM4NGOs was launched in 2010. This nonprofit’s stated mission is to maximize the impact of project investments for donors and beneficiaries. To do that, PM4NGOs pursues two primary strategies: Promote and enable professional project management practices to be contextualized for the development and humanitarian environments. Develop and maintain standards for project management in development and humanitarian agencies. To meet these goals, PM4NGOs has created a certification based on a description of project management that bridges the gap between the realities of development projects and the existing standards such as PRINCE2 and the Project Management Institute’s Project Management Professional (PMP)®. The certification is called “Project Management for Development Professionals,” but is usually referred to as PMD Pro. The accompanying standards document is called A Guide to the PMD Pro1. How do another standard and another certification make a difference? Mike Culligan is one of PM4NGOs founding board members and a principal author of the standard. He explains the genesis of PM4NGOs: “After 20 years of working on projects in the development sector I was introduced to the project management standards that were commonplace in industry. That was a revelation. But it wasn’t easy to apply them. I found that they simply didn’t connect with the way development workers were running their projects.” Other seasoned development project managers felt the same way. Culligan and his PM4NGOs colleagues want to promote proven best practices, but know that to be accepted these practices must be contextualized, described in a way that makes sense to development projects. Culligan, along with all other PM4NGOs board members, is a volunteer. His full-time job is providing learning opportunities to 59 major NGOs around the world. The freely available “Guide to PMD Pro” creates a global standard that development workers will recognize. It can be adopted by international NGOs or small, local NGOs.” The standard can also be promoted by independent training and consulting firms, just like the PMI and PRINCE2 certification. PM4NGOs puts a special emphasis on serving its unique audience. “A very important role of PM4NGOs is to make certain that access to the new certification is broad and the price affordable,” says Vadim Usvitsky, PM4NGOs board chair. “We work in an environment where professional credentials are very important but not often available. We want to make sure the PMD Pro reaches all project managers that are interested.” The members of PM4NGOs have donated their time and money to write the standard, to develop the certification exam, and to have both translated into multiple languages. They also strive to make the certification accessible by keeping the cost of the exams to a minimum, as low as $20 per applicant in some cases. Early results from the field are positive. World Vision International is using the certification as a basis for training over 1,000 field workers in 16 African countries. Dozens of development organizations in Latin America are collaborating to educate over 600 professionals using the Guide to the PMD Pro. Projects undertaken to achieve social change need proven project management practices such as planning, risk management, and scope control. They also need optimism, persistence, passion, and imagination. The founders of PM4NGOs have a grand vision and the hard-won experience to make it a reality. To learn more, visit their website: pm4ngos.org. This article is excerpted from the new book, The Fast Forward MBA in Project Management, 4th Edition. Copyright 2011. This material is used by permission of John Wiley & Sons, Inc.
Project Portfolio Management: Align Project Resources with Business Strategy
Projects fulfill a number of purposes within an organization. The categories within a portfolio make clear which purposes the projects serve. Examples include mandatory growth, cost-cutting, and sustaining projects. For example, a sustaining project could include preventive maintenance projects for current manufacturing equipment. Growth versus cost- cutting distinguishes projects that generate new revenue from projects that make the operation more efficient. Strategic goals also become portfolio categories when multiple projects become tied to each goal. Establishing portfolio categories provides a framework for allocating resources and risk. Just as a 401(k) establishes investment proportions, such as 40 percent fixed income and 60 percent equities, a project portfolio uses the categories to allocate the organization’s cash and personnel at a high level (see Figure 1). Figure 1. A project portfolio. A portfolio is made up of different categories, each of which can represent a different proportion of the overall portfolio. Within each category, projects are ranked. Whenever the steering committee reviews the portfolio, the first focus should be to review the categories and the allocation among the categories to ensure that they continue to reflect the goals of the organization’s strategy. Due to changing contextual conditions, this may require altering weights, recalculating scores, and adjusting the portfolio accordingly. PPM Information Supports Decisions Project portfolio management is intended to be a data-driven decision process. A critical success factor for PPM is the capability to provide, as one PMO manager called it, “a single source of truth.” Although PPM decisions will always be subjective — even political — accurate information that everyone can trust increases the quality of the discussions and decisions. PPM information generally consists of a list of all active and proposed projects, specific information for each project, and information about the limited resources that are being spread across the projects. The information supports both portfolio selection and portfolio monitoring. The list of all projects is critical during selection to avoid redundant projects. Portfolio monitoring information tends to include the following for every active project: The approved budget and the current forecast cost at completion. The approved completion date and the current forecast completion data. Updates to the criteria used for portfolio selection that describe strategic fit, risk, and return on investment. In addition to project-specific information, PPM typically requires an understanding of resource constraints that will affect the portfolio. At a minimum, this would include the cash flow available to fund proj ects. Recent technology advances also make it easier and more practical to include personnel availability forecasts. These forecasts prevent a firm or department from taking on more projects than its staff can handle, while scheduling projects so that all staff members are kept busy. Project Selection and Prioritization It has been said that you can’t compare apples and oranges. It is a saying that characterizes a choice between two options with different benefits and disadvantages. Choosing between potential projects frequently presents that same dilemma. A seasoned executive can justifiably rely on her or his intuition and judgment to choose between two projects, even if they are an apple and an orange. That won’t work for project portfolios. The range of projects that confront a portfolio steering committee can turn the “apples versus oranges” dilemma into a fruit salad. Consistent proposals and selection criteria put a decision-making framework in place. Stakeholders Agree on Selection Criteria Work with the steering committee to gain agreement on weighting the categories within the portfolio. Within each category, quantitative and qualitative criteria are used for ranking projects. Although criteria may change between categories, some factors are common to most portfolio ranking processes: Mandatory. Certain projects must be done, such as those needed for Sarbanes- Oxley compliance. If a project is mandatory, the question is not whether to do it, but whether the scope can be minimized. Quantitative benefits versus cost comparison. This comparison is made using a return on investment formula that quantifies the expected benefit (increased revenue or decreased costs) with the expected project and life cycle costs. Using a consistent quantitative formula makes it possible to compare projects that are otherwise quite different. Subjective. Factors such as strategic fit, customer satisfaction, and risk should all play a role. These factors can be assigned a score — such as 1 to 5 — to make them easier to compare. External. What factors outside your control — such as exchange rate or market trends — should affect project selection A car manufacturer that is comparing potential new models might have a variable that reflects the effect of the price of gasoline on the demand for proposed vehicles. Not all of these factors will count equally, which is part of the “apples versus oranges” challenge. Once the criteria are chosen, it is common to use a weighting formula that recognizes the relative importance of each factor. One goal of creating a project selection model is to gain the approval of the sponsors for the portfolio and minimize resistance by other stakeholders. Establishing the criteria exposes the different values executives use to choose projects. Expect the process to be somewhat contentious, but the give-and-take required to refine the criteria will build support for the PPM process. Create Portfolio Options and Select the Best All together, the common factors and weighting formulas provide the framework for making quantitative comparisons among projects. PPM analysis usually includes tables and graphics that help illustrate the variables. Figure 2 shows a classic portfolio bubble chart. These charts are able to show four variables by using the four variables by using the vertical and horizontal axis and the size and color of the bubbles. Figure 2. A portfolio bubble chart. As long as selection factors are subjective, the selection process is far more than just a math problem worked out on a spreadsheet. The categories and rankings are models that allow us to adjust our variables to consider different scenarios. As you adjust these variables, also watch the effect on resource allocation and expenditures. Personnel Capacity Management Is a Major Benefit of PPM PPM information systems are increasingly able to tie personnel requirements to projects, which allows personnel utilization to be a factor in project selection. Integrating personnel limitations into the process yields three major benefits. Avoid overloading the people who deliver the projects. When people spread their time between ongoing operations and multiple projects, it is easy to assign them far more work than they can realistically accomplish. PPM systems promote visibility into resource loading. Available skills can change priority ranking. Money is fungible, but people are not. If one project is taking the majority of electrical engineers, another equally high-priority project that also needs electrical engineers might have to be put on hold while a lower-priority project that uses available mechanical engineers gets the green light. Tie staffing plans to strategic goals. The projects in a portfolio line up to strategic goals. Staffing can be projected based on the forecasted projects, identifying particular skill areas that need to grow or that are overstaffed. With this resource forecast, it can be possible to increase or decrease staffing at a more deliberate rate that is more cost-effective. Whether it’s cash flow or personnel, organizations are faced with limited resources. When a PPM system sheds light on the resource constraints, the true cost of pet projects becomes more evident as we see the other projects that won’t be performed. This article is excerpted from the new book, The Fast Forward MBA in Project Management, 4th Edition. Copyright 2011. This material is used by permission of John Wiley & Sons, Inc.