Why are the wrong technology projects getting started? – who is asking the tough questions?
Douglas M. Arnstein, PMP, President, Absolute Consulting Group, Inc.
You are already managing two projects. One is consuming most of your time; the other is starting to slip due to lack of attention. At your weekly one-on-one with your manager, he asks you to get involved with an effort to determine the feasibility of decommissioning your trade finance system by moving the instruments to other loan systems, the sum of which do not fully mirror the functionality of the current system. Based on your experience, you know that this study is a small project in and of itself, and the larger project is complex from both a technical and operational perspective. You also know that taking this on will render you less productive on your active projects. Not only does your manager want an answer in three days, but he also wants to know how much it will cost and how long it will take. Have I got your attention? This is not the first paper recognizing that wrong projects get started. The point I would like to make is that we as project managers have the ability to influence these types of projects by asking tough questions, acting like consultants, and using tools such as benefit cost analyses to assist management in making informed decisions.
Asking the Tough Questions—What's the Point?
There are three reasons to ask tough questions when hearing about a suspect project. One is to stop or delay projects that are not aligned with the organization’s objectives before they consume valuable time and resources. The first line of questioning should be to determine and validate the sponsorship. Who is making the request? What are the market drivers? What are the underlying assumptions as to the benefits of the change? If your manager does not have the answers, it should be a warning that there may be neither a clear sponsorship nor a need for the project. Before going any further you and your manager should conduct some fact finding with the original requestor to determine this information since it is critical to putting a framework around the original request.
There is an overwhelming tendency of managers who are not familiar with technology to underestimate project scope. In the case of the trade finance system above, it was thought that the organization could replace a mainframe application with thousands of function points by booking the letters of credit and banker’s acceptances to existing loan systems and building a credit-reporting module by integrating a client/server vendor product that one of its clients was using to manage its outstanding letters of credit. This led to the assumption that they could implement the system within their operation quite inexpensively. This triggered several questions such as “What about data security, backup and recovery, system redundancy/availability, and network considerations.” Also, “What about the functionality that would need to be built to fully migrate the finance instruments, not to mention defining and making the numerous changes in operational processes?” These questions quickly got management to realize that this was not a small, simple project. Questions about why this was an important organizational objective led to the discovery that the current vendor system was very expensive and there were vendor management issues. Fair enough, but it is important to go into these types of projects with a realistic understanding of the costs, functional tradeoffs, and the ultimate benefits.
The second reason to ask tough questions is to eliminate noise, namely time-consuming, no-benefit activities that dilute your focus on current priorities. This tactic is for self-preservation. It buys the time to complete the active projects that you are managing. When presented with a request similar to the one in the opening paragraph, your first response should be to challenge it. Mention the scope of the feasibility effort itself and the need for time and resources to properly conduct the exercise so that it delivers meaningful results. Mention the direct and immediate adverse result that the time spent on the study would have on your active projects. Is management willing to accept that consequence? Often they are not. In those cases where your challenge fails, negotiate for management commitment to the effort—in other words, what you need to do the project right. Be specific about the time and resources needed to plan and analyze the problem to the appropriate level of detail to arrive at a meaningful outcome. If management is not willing to provide sufficient time and resources immediately, request a delay until they are available. The risk of not doing so is that the research effort returns poor, incomplete results, and your active projects suffer too. It is hard to believe that any organization would accept this outcome. The truth is that perceived and tangible pressures as well as the organization’s political climate drive activities and decisions that in retrospect lead to poor choices, wasted time, and missed deadlines on other projects.
The third reason to ask tough questions is to increase the value of the projects that are funded and started. It is the de facto result of getting management to question how projects align with organizational priorities and objectives before they are started. If the active projects were also evaluated in the same way, there is less tendency to disrupt them. This increases the importance and urgency of completing the active projects with minimal interruption. Another softer benefit is how this affects staff and the project teams. The fewer distractions they have toward completing the active projects, the more they can stay focused on current tasks. The fact that they can see how the project portfolio adds organizational value provides positive reinforcement that they are not wasting time chasing management’s capricious idea of the day. Staff can easily discern when a project on which they are working has no perceived benefit. Sometimes they are the ones who point it out and they are usually not shy about sharing that information with anyone who will listen. We have all seen how this can poison the project environment. Asking tough questions and using our influence to assist management in making good project decisions is one way to combat the negative ripple effect that wrong projects can have.
Asking tough questions when asked to get involved in questionable projects may seem difficult and be perceived as a careerlimiting move. My experience has been the opposite. It is often scary to be the one to speak up and get others to think more clearly about what is being requested. Nonetheless, the result is that an appropriate dialogue gets started before a lot of time and money are spent. This benefits the organization, your management, you, and your current, active projects.
The Project Manager as “Consultant”
Our job is not only to manage projects, but also to lead and influence, often without formal authority. This means being an active “consultant” to our projects and organizations. According to Peter Block in Flawless Consulting, a consultant is a person in a position to have some influence over an individual, a group, or an organization, but who has no direct power to make changes or implement programs (Block 1981,1). Ultimately, this means that we want to use leverage and make an impact. Leverage and impact mean that our expertise gets used and our recommendations accepted (Block 1981, v). That you are a full-time employee at an organization or a contractor is irrelevant although each is presented with somewhat different challenges. Essentially, an internal consultant is a known quantity from a departmental and rank perspective and may be rated on the success of the project, which can affect raises, bonuses, and promotions. There may also be history as it relates to working with other departments and staff. Depending on the organization’s communication culture, these attributes can affect an individual’s ability to move within the organization to engage support and develop information critical to the project. An external consultant does not have these same restrictions, although being an outsider and unknown quantity can sometimes hamper that same ability. According to Block, the one attribute that both internal and external consultants share is their underlying anxiety, namely that they both fear being ignored, rejected, and treated as unimportant (Block 1981,107). Nonetheless, although the challenges are different, we should all be focused on the same outcome; helping our clients and organizations get beneficial projects started and nonbeneficial projects rethought or postponed.
Managing projects involves the experience we bring to bear on our projects, namely what we have seen work and not work in the past. It is this aspect of our experience that allows us to function as consultants. In the situation of wrong projects getting started, we need to bring a dispassionate perspective to the discourse and provide the decision-makers with the informed, objective view. As project management consultants, we need to question assumptions, explore unstated options, and bring to light hidden objectives. Armed with this information, it is a much easier task to shift the direction of the thinking toward a sensible plan. However, none of these activities are done in a vacuum. It is important for the consultant to understand his or her needs as it relates to doing the job (Block 1981, 13). These can include access to the appropriate people in a timely manner, support from the project sponsor, and the appropriate desktop software for creating the work product. Negotiating for these is an important pre-step to getting started on any project.
Referring back to the trade finance project discussed in the opening, let’s assume that we have finished our active projects and we are starting the feasibility study. The first objective is to use the available information to get the sponsor an answer as quickly as possible. Senior management is probably not looking for a detailed plan at this point, but they are obviously interested in understanding whether the project has enough merit to pursue. A Guide to the Project Management Body of Knowledge (PMBOK® Guide) points out in Project Scope Management that in some organizations, a project is not formally initiated until after completion of a needs assessment, a feasibility study … or some other equivalent form of analysis that was itself separately initiated (PMBOK® Guide 2000, 53).Whether the project manager purist in each of us likes it our not, we are often asked to produce information (time, cost, resource requirements) with what could best be considered incomplete information. What follows is a strategy for doing so.
My recommendation is to focus on Project Scope Management defined in the PMBOK® Guide as the processes required to ensure that the project includes all work required … what is or not included in the project (PMBOK® Guide 2000, 51). As mentioned earlier, there is an overwhelming tendency to underestimate what it takes to make a technology change, test it, and ensure that it meets its business objective. Many projects start based on inaccurate or incomplete assumptions. It is therefore important to query the sponsor and determine his or her underlying assumptions. I would recommend gathering similar type information as from a Stakeholder Analysis, including how the sponsor defines the project objectives, what the sponsor defines as the project scope, how the sponsor defines critical success factors for the project, how the sponsor defines project quality, and what the sponsor knows to be true that will affect project performance? It is also important to extend this information gathering to other key stakeholders as well. One needs to obtain as much information as possible to understand the true project scope, not just what the sponsor thinks it is. One must also set realistic expectations as to developing the benefit cost analysis. Management and interested parties always want to know how much is it going to cost and how long will it take. Gathering and distilling that information is not a two-day exercise. Based upon the information provided by the sponsor, an experienced project manager should be able to estimate a realistic schedule for developing benefits and costs.
Exhibit 1. Benefit Cost Analysis Overview by Section
At this early stage in the project life cycle, absent business requirements, management’s awareness of the tradeoffs is critical to ensuring that the right project gets started once justified. Telling management what they want to hear is the surest way to get the wrong project approved. With the help of other project planning resources, find out what management needs to know. Will the programming be done internally, by a vendor, or split between the two? If a vendor is involved, factor in the probability of escalating costs. Besides the application system changes, are there other technology factors that need to be considered within project scope? How stable or segregated is the development environment and is work required to prepare it for your project changes? What level of testing is required and will there be separate and distinct testing environments? Do they exist today, or will they need to be built? Does network infrastructure need to be built or upgraded? How extensive will the back office operations procedural changes be? How many operations groups will they affect and are staff centrally located or geographically dispersed? When the sponsor states that the existing system is expensive, are you asking, “Expensive compared to what?” Once all the above items get factored in, what seemed like a small and straightforward project in the sponsor’s mind gets more expensive. The effect this has on benefits can turn a winner project into a loser, solely because the assumptions were incomplete.
In our roles as experienced project managers acting as consultants, we have the ability to continue to ask questions that define scope and isolate the information that the project team needs to conduct its feasibility analysis. We know the level of information that is needed and we know how to get it. We know how to engage the other internal organizations to assist us in this endeavor. We also have ways to present that information so that management can make an informed decision.
Selling the Project
Selling the project is a joint effort between the project sponsor and the project manager. The sponsor’s role at this point is to describe the project. An excellent place for the sponsor to start is to draft a project charter, one of the outputs of Scope Management Initiation (PMBOK® Guide 2000, 54), and the document that formally authorizes a project. Have the project sponsor articulate the business drivers and benefits, project objectives, other internal organizations with a stake in the outcome, and his or her definition of what constitutes completion of the project. As it relates to the business benefits, it is important to articulate tangible and intangible benefits. In some cases, the intangible benefits can influence the decision to proceed or not. Understanding the market drivers and competitive challenges are important to the final decision. Some projects do not pay for themselves; others may not meet corporate financial objectives or guidelines. If so, the organization has to be able to justify the investment based on other criteria such as the intangible benefits.
The project manager’s role is to gather the more detailed information and complement the sponsors’ information with further assumptions, project constraints, and a financial analysis. Assembled together, this information should provide compelling reasons to continue, postpone, or cancel the project. While the sponsor is working on the project charter business case, the project manager is developing the benefit cost analysis, one of the Tools and Techniques in Scope Planning. There are several methods for measuring benefits against costs, such as return on investment or payback period (PMBOK® Guide 2000, 56). I am going to focus on the payback period method and present a specific model for quantifying and presenting the project financial data. The benefit cost analysis involves estimating tangible and intangible costs (outlays) and benefits of various project alternatives and the using the methods referred to above to assess the relative desirability of the identified alternatives (PMBOK® Guide 2000, 56). Over the years, I have developed a benefit cost analysis template that can handle a multiple-year development period for one-time costs, and a three-to-five-year payback period for identifying recurring benefits and costs, all on a one-page letter-sized, landscape-oriented document. In addition, the model allows for identifying subproject costs for these same attributes and rolling them up to a total project cost. It is an extremely useful tool, and I have used it successfully to sell projects and to make the case to cancel projects.
Exhibit 2. Benefit Cost Analysis Overview by Area
Exhibit 3. Benefits Section
The document is divided into three sections as identified by the rows and three areas as identified by the columns. The three sections are the Header, the Benefits, and the Costs. The Benefits are presented for recurring incremental revenue and expense reductions, and the costs are presented for depreciable, development, and recurring costs.
The three areas are the row name (i.e., the category description of the benefit or cost), the development period costs, and the annual recurring benefits and costs.
The top section is the Header. It documents the project name, sponsor, and sponsor division, and any other information that is appropriate to identify the project within your organization.
The next section is the project benefits. Two types of benefits are presented, incremental revenue and expense reductions. The incremental revenue category captures projected increases in revenue that would be realized by the project outcome. In the category of expense reductions, list items such as staff reductions, vendor license reductions, reduced costs of production, telecom savings, and any other benefit that can be calculated as a dollar amount. In the earlier trade finance example, the business was certain that it could eliminate certain staff positions as well as reduce vendor license fees. On another project to automate and archive periodic client account statements, savings were identified in the following categories, reduced paper and postage cost by printing on both sides of the paper, reduced labor cost in statement fulfillment, elimination of costly microfiche, and vendor license reductions. For each item, calculate the amount of the benefit. For example, in the case of labor cost, a full-time equivalent employee is paid at an annual rate of $50,000 with a 30% payroll benefit factor for a total of $65,000 annually. If the business calculates that one staff member could be reduced, then the annual savings would be $65,000. The projected benefits for all categories are then populated into the annual recurring benefits area by year. In the benefits section, the development period area is not used.
The next section of the benefit cost analysis is the Cost section, which is divided into three subsections—depreciable costs, onetime development costs, and recurring costs. The first subsection represents the capitalized costs for hardware, software, and any other asset subject to depreciation. I have found it useful to create a separate worksheet within the spreadsheet to document the hardware, software, and other depreciable assets separated by type, for example, desktop hardware, server hardware, desktop software, server software, and other. This is done because some organizations treat their depreciation schedules for the asset types differently. They might use a 24-month period for desktop assets and a 60-month schedule for server assets. Building the asset detail within a separate worksheet and linking it to the appropriate cell in the depreciation subsection allows for flexibility within the formulas to calculate the depreciation for the different schedules. Documenting the assets in a separate worksheet also allows for making additions, changes, and deletions to the lists without affecting the formulas within the depreciation subsection.
Exhibit 4. Hardware Software Worksheet
Exhibit 5. Costs—Depreciation Subsection
Using the asset totals for each category from the hardware software worksheet and the appropriate depreciation schedule for the corresponding asset, build the appropriate formula and calculate the annual depreciation cost for the asset type. The formulas are then populated into the annual recurring cost area. For the depreciable assets, I use the project development period area to display the purchase costs for each category, but this information is not summed anywhere. Only the depreciation amounts calculated in the recurring cost area are used in the evaluation of the payback period.
The next Cost subsection details the project development costs, the one-time cost to create the end product based on the scope statement. Because most projects do not start on a year-end boundary and they can take more than 12 months to complete, I use a two-year development period for most of my models. However, the estimated project duration should dictate how many years one uses to calculate the development costs. The development categories will be dictated by the needs of your project, but generally these fall into areas such as software development, vendor expenses, travel, legal fees, network infrastructure, premise costs, non-depreciable hardware software, and project labor costs. The costs are calculated for each category specific to the project and are mapped into the appropriate development year. The recurring cost area is not used for the project development costs.
The last Costs subsection is the recurring or ongoing costs articulated over the three-to-five-year period. It documents incremental costs incurred because of the outcome of the project. These could include incremental labor, such as new computer operators to run the system or customer support staff, new software licenses or maintenance costs, data center chargebacks, or increased telecom expense to name a few. These are calculated and populated into the recurring expense area. The development cost area is not used for these recurring costs.
Exhibit 6. Costs—Development Subsection
Exhibit 7. Costs—Recurring Expenses Subsection
As mentioned earlier, one can create a separate benefit cost worksheet for each subproject associated within the overall project. For example, in the statement automation and archival project, the automation and archival components were separate and distinct efforts that were executed by different technical groups. The benefits and costs were articulated for each and then summarized from the overall project perspective all within one spreadsheet. One last recommendation regarding the development of the estimates is to create a separate worksheet and document the assumptions from which the numbers were estimated. For example, “labor savings the first year represent one staff member for four months at $5,417 per month because the system was implemented in August,” or “network infrastructure development costs assume the reconditioning of the network on the fourth floor in building 8, including $500 for cabling and $250 for switches.” These assumptions come in handy when reviewing the spreadsheet months later as to how a specific number was derived.
It is now time to finalize the benefit cost analysis. To summarize the benefits, add the incremental revenue line with the expense reduction totals. Total the one-time project development costs by year. To calculate the total recurring costs, add the recurring annual depreciation to the recurring expenses. By comparing the recurring annual benefits to the sum of the one-time development and recurring costs, the payback period can be determined. Schedule a review with the project sponsor and other key stakeholders. The numbers should give a good indication whether to pursue, postpone, or cancel the project. Often the review generates new ideas or different thinking which may require some further analysis and reestimation. This is good. It engages the sponsor and the stakeholders and can often lead to refinements that turn a negligible project into a better one.
Getting the right project started involves nothing other than clarifying project objectives with the key stakeholders, refining scope to the extent possible, developing estimates, and presenting a well-constructed benefit cost analysis to sell the project. Ask the right questions; get the appropriate answer. In doing so, the nonbeneficial projects will be cancelled or postponed until a better business case can be made, and the right projects will proceed with a strong, clear sense of need and benefit.
Peter Block. 1981. Flawless Consulting, A Guide to Getting Your Expertise Used. San Diego, CA: Pfeiffer & Company.
Project Management Institute Standards Committee. 2000. A Guide to the Project Management Body of Knowledge (PMBOK® Guide). Newtown Square, PA: Project Management Institute.
Proceedings of the Project Management Institute Annual Seminars & Symposium
November 1–10, 2001 • Nashville, Tenn., USA