Why does capacity need to increase or cost need to decrease?This book is about what you, as functional manager, need to excel in bringing meaningful change to your organization. A fundamental understanding of project management is one step; understanding your role in the provider/customer relationship is another. Now you must acquire the skills to complement those of your provider. This chapter addresses the first of the four critical skills you need, which, to recap, are:
1. Articulating the real customer need and business case for your project.
2. Staying focused on project deliverables.
3. Understanding your key project dependencies.
4. Being proactive about project risk.
A skill lacking in many projects is the ability to find and articulate the real customer need, a need that is met by a mission. This skill must be applied during the initiation of projects, but often is glossed over. If you expect a project team to deliver results and the project to provide the desired benefits, you must play a central role in articulating the need. Users have a sense of the needs, but do not realize their implications. Sponsors and executives know the benefits they want, but often do not fully understand the details of how to get them. This is where you fit in. You must be able to translate the sponsors’ vision into real needs, potential solutions, and process changes.
Failure to pinpoint the need accurately will likely result in the project team formulating a plan or solution that does not truly fit. Make sure your project team does not presume to know a solution before discovering, understanding, and articulating the real business need. You, as the functional manager and the customer, must ensure that the needs are clear to the project team so that they can draft a compelling mission statement for the sponsors’ review. Project managers generally react to what is handed off to them, accepting what is written in the charter at face value. Such documents often are written hastily to meet a governance requirement and usually do not convey the true mission of the project. Every project needs an “elevator speech” and the mission statement is your elevator speech—it keeps you connected at the hip to your provider and other key stakeholders throughout the project.
The presumption of a plan, requirements, or a solution should not precede identifying the real need and crafting a response in the form of a clear mission. Do not allow your project manager to jump directly into studying requirements without exploring the real need. If this happens, your project plan will be fundamentally flawed from the start.
Understanding the real need of your project is a discovery process, one that involves continual dialogue and collaboration, which implies that a relationship must exist between the provider and customer. Discovering the real need requires you and the project manager (the customer/provider partnership) to pursue an open and honest dialogue with the customer and advisory team members. The dialogue should include questions such as:
Why does capacity need to increase or cost need to decrease?
How much does it need to increase?
How is it measured?
What if this need is not met? What happens? Who is at risk?
Who ultimately benefits from having these needs met?
The questions must be pursued vigorously and satisfactorily answered if everyone is to comprehend and buy into the mission. Once you have the answers, you can complete the following critical steps:
1. Produce a compelling project mission statement based on real needs.
2. Create a meaningful current state and future state comparison.
3. Base your requirements on the business process.
4. Understand the business case for your project.
Two clear statements must be made to create a sense of urgency and a vision for your project. The first is a need statement that addresses why the organization must change or react to circumstances. The second is a project mission statement that addresses how the organization will act. An organization’s need is met by a mission and this mission resolves the need.
An essential skill is understanding what you want, then articulating it accurately and in a meaningful manner so that stakeholders can understand it consistently and it generates a sense of urgency. The skill of articulation takes practice, a strong command of the language, business acumen, and project management knowledge.
Begin by validating the articulated need with primary and secondary stakeholders and gain agreement upon a need statement. Share this statement with all of the indirect stakeholders and advisory team members so they can begin to identify and comprehend the impacts and risks that will affect your strategy.
Help those involved think about the end state so everyone gets a sense of when completion has been reached. Graphics, even quick sketches on paper or a white board, can be particularly helpful in generating dialogue that leads to crystallizing the end state. Your need statement should be truthful, specific, and eye-opening. It should articulate what is needed and why. The paragraphs below identify two types of need statements to use in clarifying your project mission.
Need Statement: “The Operation Division of ABC Company needs to reduce per unit production cost by 25 percent, increase production capacity by 50 percent in two years, and grow market share by 10 percent annually to provide satisfactory return to investors and provide our employees with long-term career growth opportunities. These needs, critical to securing the future health of our organization, will require unprecedented commitment, collaboration, and innovation from our employees and partners.”
This need statement clearly identifies a group or organization that is responsible for accomplishing the mission and enumerates attainable, measurable goals. A good statement aligns with stakeholders’ long-term interests rather than short-term personal goals. It should acknowledge the challenges and risks associated with the undertaking and recognize the potential sacrifices the organization may need to incur in order to satisfy the need. This is especially important because many people will be taking on extra duties beyond their normal jobs to accomplish it.
A useful need statement also could be more modest than the one above.
Tactical Need Statement: “The Human Resource Department of XYZ Company needs to provide immediate access (two minutes or less) to employee records and reduce manual filing and storage costs by 75 percent annually starting in the first quarter of next year. By providing improved access to employee personnel records, we will better serve our valued employees by adding three staff members to recruit and train new employees.”
These need statements are essentially the same as goals and objectives; however, stating the need implies more urgency and focus. Goals and objectives often become wish lists and fade over time. Need statements must keep the vision alive, sustaining urgency with unity that keeps the compelling vision of mental images or pictures that captivates people’s imaginations.
In your need statement, avoid vague words and phrases such as “improve customer satisfaction,” “automate processes,” and “reduce costs.” The “how much” and “why” are missing.
Remember, a strategic organizational need is met by action—a project mission. This mission attempts to resolve the need. The project mission statement aligns your project with organizational strategic goals. This statement should be short, precise, and bold. The format is: “This project will create deliverables to be used by a customer(s) to achieve specific objectives.” Begin to develop specific project objective statements to satisfy the need by explicitly stating what your project is creating, who is using it, and what benefit they hope to achieve. (Also see the section in Chapter 2, “Basic Steps to Planning Projects,” pages 37–57.) To practice, we will evaluate some customer needs and craft corresponding mission statements or project objective statements, revising and updating them along the way.
Example One. Your organization is facing new regulations that go effect in six months; these regulations require changes to how customer data is protected. Failure to comply will result in fines up to $1M, bad publicity, and loss of customers.
The mission is primarily one of protecting customer data. This could include dozens of systems and processes that spin up an entire program of projects. But keep the focus on your functional responsibilities: you manage the fulfillment of customer orders. You have partners—shipping companies and wholesalers—who rely on customer data. You have to update your systems that send and receive information to these partners to be compliant with a new security standard and ensure that certain customer data is provided only on a need-to-know basis. What would your project mission statement look like?
Try to fill in these blanks. “This project will create ______________ main deliverable) to be used by ______________________ (primary customers) to achieve _______________ (specific timed objectives).”
The result may look something like this: This project will create a new electronic data interface (project’s main deliverable) to be used by our fulfillment partners (primary customers) to achieve compliance with federal regulation XYZ by December 31 (specific timed objectives).
The objective is very clear: compliance by a certain date. The project’s product, a new electronic data interface, is still general, but it clearly focuses the effort on the technology and less on the process. The primary customers are clearly identified: those involved in handling data outside your organization who are also involved in fulfilling orders. This is a good start. But these statements are the basis for scrutiny, which is what you need to be successful. As you begin to review this mission statement with primary stakeholders, your subordinate, who manages a help desk for your fulfillment partners, asks about the particulars of the customer data being protected. “My people can’t do their jobs the same way if our partners don’t have access to customer payment information,” she points out. Now you have business processes that are impacted by this new interface. It is no longer purely a technology project.
You then meet with one of your fulfillment partners; they indicate that they are changing their process to comply with the regulation and implementing new technology to streamline operations with partners like yourself. This project is getting significantly more complex by the day. You begin to refine and update your mission statement. Separate from the project’s main deliverable of an electronic data interface, you begin to consider additional deliverables and other customers. Each of these needs its own mission statement, which, ultimately, you will bring together in the final project mission statement.
This project will create a new help desk process (project’s main deliverable) to be used by our internal fulfillment call center (primary customers) to achieve compliance with federal regulation XYZ by December 31 (specific timed objectives).
And, perhaps, this project will create new business processes with our largest partners (project’s main deliverable) to be used by our fulfillment operations (primary customers) to achieve compliance with federal regulation XYZ by December 31 (specific timed objectives).
Within your project, different customers are emerging with different needs. The project is starting to encompass not only an electronic data interface, but a new process and possible system changes for your internal fulfillment center and a new process for use with your largest partners. The challenge is trying to capture all of this in one clear, concise mission statement that identifies potential competing interests of primary and secondary stakeholders. This is not easy and must not be shortchanged. This statement should convey real meaning and imagery to your project organization. Try to write a mission statement that embodies all of these components.
It may look something like this: The Fulfillment Customer Data Protection project will create new business processes and update existing systems and data exchange interfaces (project’s main deliverable) to be used by our fulfillment operations and fulfillment partners (primary customers) to achieve compliance with federal regulation XYZ by December 31 (specific timed objectives).
Or maybe this: The Fulfillment Customer Data Protection project will create new processes, interfaces, and system modifications (project’s main deliverable) to be used by our fulfillment operations (primary customers) to achieve compliance with federal regulation XYZ by December 31 (specific timed objectives).
You and your project manager must work closely with primary and secondary stakeholders to refine this mission statement until everyone understands it. It is not science; it is art.
Example Two. Your organization’s rapid growth has resulted in decreased customer satisfaction. Current business processes and systems are not scalable to meet customer growth. The inability to stem the increase of customer complaints could result in multimillion-dollar lawsuits, bad publicity, and loss of customers.
The need is primarily one of improving customer satisfaction. As in the previous example, this could include dozens of systems and processes. You are the manager of several call centers around the globe and your people have direct interaction with customers. Your call answer times are increasing at an alarming rate, customer retention is dropping, and the number of inquiries from legal for customer history logs and transcripts has increased. What would your project mission statement look like?
The Call Centers Customer Excellence project will create new scalable business processes (project’s main deliverable) to be used by all of our call centers (primary customers) to achieve improved customer satisfaction (specific timed objectives).
In this example, the objective of “improved customer satisfaction” is not specific or timed. Second, customer satisfaction is impacted by more than just your call centers. Your call centers feel the brunt of the lack of customer satisfaction but are not the sole cause. Your boss may be focused only on trying to improve the numbers, such as call response time, when much more fundamental needs may exist. These might include improvement of product quality, more knowledgeable sales forces, or updated product information on the website.
As you begin to review this mission statement with the sales manager, you become aware that information on the website is often outdated, creating customer expectations that are out of line with actual purchases. One of your subordinates tells you that customer service representatives keep getting calls routed to them that should be routed to product support. The product support manager indicates that product development does not keep product specifications updated. And the product development manager says that marketing research keeps changing product requirements.
At some point, you have to determine how big this project is going to be and what you can successfully impact in your role as functional manager. Trying to tackle all of these issues will make the project much more than a call center project. You have to determine what is within your span of control and influence and what you can successfully change. You decide that the call routing issue is a big one. You are one of the primary users of that system. You have good relationships with the other functional managers who use the system, so you decide to focus on resolving that problem first. Now your project mission statement may look something like this:
This project will create a new call routing scheme (project’s main deliverable) to be used by our global call centers (primary customers) to reduce average call times by 15 percent within three months (specific timed objectives).
This provides a more measureable outcome, it focuses the project’s product on the call routing system, and it defines the primary customer. Working from this, you can more definitely define your primary and secondary stakeholders, define deliverables and requirements, and get your project moving. A key question still remains: is reducing call time really going to improve customer satisfaction? It may make your boss look good, but will customers be more satisfied? It could be that the root causes of customer complaints are still masked. To address this, you decide that, once the call routing scheme is implemented, you will focus on reducing customer calls by 10 percent by partnering with product development and product support to get more accurate, updated information on your organization’s website product catalog. This project is bigger and more complex and its mission statement more challenging.
This project will create a new product catalog update process (project’s main deliverable) to be used by our customers (primary customers) to reduce customer support calls by 10 percent within 6 months (specific timed objectives).
To achieve the benefits your management expects, you and your stakeholders must fully understand the changes to business processes surrounding the overall change. The way to accomplish this is to compare your current processes with a desired future state process.
Creating is important to project management because it involves more than mere problem solving, which tends to lead to temporary results. The act of creating, inspired by a compelling vision, leads to permanent results. The creative provider/customer partnership addresses the underlying issues and tensions to devise new solutions in these current and future state processes, rather than temporarily adjusting the same old situations.
Your project has two components: current reality (where you are) and desired vision (where you want to be). The discrepancy between them creates tension that must be resolved by primary stakeholders. Only then can the organization’s needs begin to be addressed through the project mission with the willing participation of secondary stakeholders, users, and other participants.
Comparing your current reality with your desired vision exposes subtle or even substantial changes to you and your provider that your executives may not have considered. The action of creating current and future states processes helps unite primary and secondary stakeholders and uncovers potential resistance areas and opportunities. At the same time, it may bring up political issues that are uncomfortable to discuss. It may expose stakeholders’ lack of understanding of the business. If you are doing this well, you probably are creating new insights, maybe a level of friction, and even some confusion. But this is the critical work of leading projects. Laying out current and future processes next to each other should create a discrepancy, which generates tension that must be resolved at an organizational level. Comparing current and future states creates energy to bring about the desired state.
Business process modeling creates visual maps of a process. It identifies the specific steps involved and who does the work, meaning those steps done by people (decision logic, manual steps) versus steps that are automated by systems.
This process begins with mental construction of business processes and gathering high-level requirements. You do not have time to document an organization’s business processes in their entirety, but these processes usually are documented already or can be constructed at a level that creates linkages between major processes and identifies inputs and outputs across business units.
Business process knowledge is critical for a functional manager to understand the inner workings of his or her organization. The challenge for you and your project manager is that people involved in these processes, as I pointed out in Chapter 3, often don’t speak in business process terms, but in transactional terms. People are typically so close to their day-to-day work that they cannot see the bigger picture. Your role is to facilitate asking good questions and quickly translate responses into process terms, form a mental picture, and then validate any assumptions or clarify outstanding questions. Some practical steps to quickly gain knowledge of a business process are:
Identify the major process activities of each organization and the relationships between them.
Document major inputs and outputs to each process.
Identify the customers (internal and external) of the processes.
Identify the suppliers of the goods or information into the process.
Discover why certain activities are performed.
Identify the key metrics (actual and desired) of major processes and activities.
Before going any farther, let’s make sure you understand some of the terms your provider may be using. You’re acting in partnership and must show a united front to your stakeholders. Your project manager may be trained to use specific business process modeling methods. One is ITIL® (Information Technology Infrastructure Library®), which is used for information technology (IT) service management. It provides a practical framework for identifying, planning, delivering, and supporting IT services to a business. ITIL advocates that IT services must be aligned to the needs of the business and underpin the core business processes. It provides guidance to organizations on how to use IT as a tool to facilitate business change, transformation, and growth. Five core guides map the entire ITIL service life cycle, beginning with the identification of customer needs and drivers of IT requirements, to the design and implementation of the service into operation, and finally the monitoring and improvement phase of the service.1 ITIL is not a business process modeling tool per se, but an overarching methodology to improve IT management services, of which process modeling is a component.
Another method is IDEF (Integrated Definition Methods), a process modeling standard developed by the United States Air Force in the 1970s and standardized by the federal government in 1993. An IDEF model consists of a hierarchical series of diagrams, text, and glossary cross-referenced to each other. The two primary modeling components are functions (represented on a diagram by boxes) and the data and objects that relate to those functions (represented by arrows).
IDEF introduces greater levels of detail by drilling down through hierarchical levels to new diagrams. Each diagram includes just a few boxes. Because the fundamental element of an IDEF process chart is a function, it does not provide a clear picture of process delays. It also does not provide the detailed relationships between documents, and seeing how a piece of the process really fits into the big picture may be difficult with IDEF.2 Figure 6-1 illustrates a simple order process using IDEF process mapping methodology.
You probably have heard someone talking about Six Sigma. This is a quality management program to achieve six “sigma” levels of quality. It was pioneered by Motorola in the mid-1980s and has spread to many other manufacturing companies as well as to service companies. The objective of Six Sigma Quality is to reduce process output variation so that, on a long-term basis, which is the customer’s aggregate experience with the process over time, the result is no more than 3.4 defect parts per million (PPM) opportunities. The system’s DMAIC3 is a basic methodology to improve existing processes:
Figure 6-1 IDEF Simple Order Process
Define out of tolerance range.
Measure key internal processes critical to quality.
Analyze why defects occur.
Improve the process to stay within tolerance.
Control the process to stay within goals.
DMADV4 is the basic methodology of introducing new processes:
Define the process and where it would fail to meet customer needs.
Measure and determine if process meets customer needs.
Analyze the options to meet customer needs.
Design changes to the process to meet customer needs.
Verify the changes have met customer needs.
Business process modeling is a key component for both the Measure and Improve phases of the DMAIC methodology. Managing and improving processes is the core of Six Sigma. And in order to truly understand a process, identify challenges, and make improvements, the details of the process must be clarified. Only by creating a detailed process map based on inputs from those who perform it and reaching agreement that it does, in fact, reflect reality rather than expectation can customers and project managers gain a full understanding of an existing process. Six Sigma analysts like to use the acronym SIPOC or refer to SIPOC diagrams. SIPOC stands for:
Suppliers: significant internal/external suppliers to the process.
Inputs: significant inputs to the process. This would include things such as materials, forms, information, staff, etc.
Process: in a diagram, one block represents the entire process.
Outputs: significant outputs to internal/external customers. This would be anything the business unit distributes. Frequency/timing is listed with the output. Examples of outputs would be reports, ratings, products, documents, etc.
Customers: significant internal/external customers to the process. This would include anyone who receives outputs. The customer must get the output directly from the business unit and does not necessarily have to be a user of the output. If the output is received from a third party, the recipients are not customers. Examples of customers could be managers, CEOs, boards of directors, or other departments.
Regardless of the method, don’t be intimidated by your project manager’s use of all these fancy terms. The bottom line is that your partnership needs to produce a current and future state process that tells a compelling story.
A basic flow chart documents a flow of work that may combine human processes with system processes. Figure 6-2 illustrates a basic process of collecting past due accounts.
This type of diagram attempts to illustrate the entire series of steps of a process from beginning to end. It should illustrate loops, parallel processing, automation, and system interactions. Stakeholders can easily get lost in these maps, which can become very complex when human- and system-related processes are combined.
A common variation of this approach is called a swim lane diagram or a cross-functional map chart. These diagrams divide the flow chart into rows that represent the locations or people involved in the process. When the process flows to a different area, the flow line moves to a different row. This type of map provides high-level visibility over the areas involved; it is still limited to a single line flow, which, by its nature, is high level. It may not provide visibility over multiple items or illustrate parallel processing. But it does an excellent job of showing the work of different groups or functional units and their interactions.
I recommend starting with a simple swim lane or cross-functional diagram. The first goal is to identify in the swim lanes the functional units involved in the current state. Of course, always start with current state to ground yourself and your team. Stay away from system processes, such as updating this database, or this system sending data to this other application. Diagrams can get complex very quickly. If the process is not accurate, customers lose confidence in your leadership. Focus on what the people do; the system interactions will come next.
Figure 6-2 Sample Flow Chart for Collection of Past Due Accounts
Let’s revisit our first project objective statement. The Fulfillment Customer Data Protection project will create new processes, interfaces and system modifications (project’s main deliverable) to be used by our fulfillment operations (primary customers) to achieve compliance with federal regulation XYZ by December 31 (specific timed objectives).
The current state swim lane can be constructed showing the functional units. The cross-functional map simply illustrates the major constituents involved in the current state process: Fulfillment Help Desk, Fulfillment Operations, Order Processing, Strategic Partners, and All Other Partners.
Next, you begin to work with your team to document the current understanding of the process. The example in Figure 6-3 is a simple hypothetical order fulfillment process. Enumerating the process steps allows for companion documents to identify which systems are used, what key features and functionality exist in the current process, and the key metrics to measure the process. The dark boxes are processes that are now subjected to the new regulations, sharing customer information with partners.
Figure 6-3 Cross-Functional Process Flow, Current State
Order processing takes in new orders from customers; however, the website orders bypass this functional group and go directly to Fulfillment Operations for address validation. If the address is not valid, the order gets handed off to the Fulfillment Help Desk, which contacts the customer to determine the proper address. For instance, FedEx does not deliver to post office boxes, so if the customer used a PO box as a shipping address, the order would stop until a proper address was attained. To be fair to the Fulfillment Help Desk, they handle many other issues besides tracking down invalid shipping addresses. Eventually, the order will be processed by Fulfillment Operations, whose primary responsibility is to ensure that an accurate order—product number, shipping arrangements, and pricing—gets batch-transferred to their strategic partners in an overnight computer process. Some products do not get fulfilled by strategic partners but by other partners. This requires more manual processing; thus, it is handed back to the Fulfillment Help Desk to work with the other partners to arrange for product delivery.
This work is more art than science. The value is generating an accurate understanding of how business is done today and uncovering little nuggets of information that are only known to a few people. Once the draft of the current state is complete, circulate it or call a meeting and review it with key stakeholders to gain consensus.
The future state process does not need to use the same swim lanes as the current state. New swim lanes can be added and others removed if the current process is being changed enough that it changes the responsibilities of the functional areas.
As you discuss the future vision, create the new process map, as shown in Figure 6-4. The discussion should start with metrics: “Today we perform at this level; tomorrow we must perform at this specific higher level.” With those new metrics in mind and some knowledge of the technology or solution that can improve your business process, you begin to create the desired state, identifying how your organization would like the business process to work.
Figure 6-4 Cross-Functional Process Flow, Future State
After much discussion, meetings, and brainstorming sessions, the future state process for our hypothetical situation is fundamentally different from the current state. For one thing, all partners will receive information via the new electronic data interface (EDI). Some smaller partners may have to be terminated if they cannot upgrade their ability to receive order information electronically. A new swim lane for the customer has been added because the current state process was not focused on the customer but the future state will put an emphasis on customers using the website instead of calling in orders. This may be a culture change for some customers who have established relationships with order processors and prefer a personal touch to their transaction. Finally, because all orders will run through this EDI immediately after receipt, the interface will be built with the capability to integrate with other databases and external systems to validate that customer information is complete with a valid shipping address. This eliminates the need for the Fulfillment Help Desk to contact customers and partners, which comprised much of their time. Therefore, a decision is made to consolidate the Fulfillment Help Desk and Operations into Fulfillment Services to make the organization more responsive to the leaner process.
Your goal as functional manager is to ensure that stakeholders buy into the shifting of work from one unit to another and the automation of manual processes. Comparing the current and future state business processes should create a compelling message and provide everyone with new insights and confidence.
Disconnects and Difficult Decisions. Developing current and future state processes is my favorite part of any project. By the time you get to this point in the project, most all of the stakeholders have agreed on the need for business process improvements. Unfortunately, they often don’t realize what is required to achieve them. First of all, developing current state maps makes it very obvious how much stakeholders really know or don’t know about the business process of which they are a part. Often, eye-opening discussions reveal disconnects between departments and employees. I remember an employee of a customer service department recommending to the manager of the product development department that they review and update their policy for allowing returns since many changes had been made in the product line and the technology over the past five years. The manager of the product development department, who had been on the job for about one year, had no idea that the policy existed. Although it was written prior to his arrival, this was his department’s policy. He had no clue that customer service representatives were using outdated guidelines issued by his department.
Future state processes also create a necessary tension in the organization that must be resolved in order to make progress. Too often, stakeholders buy in to generic project objectives and goals and leave the dirty work to project teams that really don’t have the authority to enforce difficult and unpopular decisions.
A clear example of this was a mortgage company’s workflow redesign that I managed several years ago. The paper-based process was mapped out in detail and the inefficiencies were very obvious: multiple copies of loan files, lost files, huge delays in processing during peak periods of the month, etc. The department responsible for receiving loan files from closing agents around the country was skilled at processing closed loans and setting them up on the loan servicing systems. But as the organization grew, this process of receiving hundreds of overnight delivery packages, inventorying them, and logging them as received in a tracking system had become a gigantic effort during the last week of each month. It was apparent that the department lacked the organizational management skills to handle the peaks and valleys of this process effectively.
Once the current state was documented, the future state became nothing less than a strategic organization restructuring for this division. This was not anticipated at the outset of the project. The conflict boiled down to whose department’s name would be on the future state swim lane responsible for receiving closed loan files and digitizing them within a strict service-level agreement of two business days. The incumbent department could not fathom anyone else doing this work, but it was clear that dealing with new technology and an assembly-line process with strict performance metrics was not the department’s culture. They were more problem solvers than production line workers.
Ultimately, the work was transferred to another department whose expertise in microfilming was a much better match. This decision was not taken lightly; off-site meetings were held to explain the organizational changes and the impacts to administrative workers whose jobs had not significantly changed in 5, 10, or even 15 years. Some workers were moved to the other department, others were reassigned, and others left the company altogether.
The promise of future state process improvements usually requires some hard decisions. As a functional manager, you need to help drive those decisions and not let your ego get in the way.
Using the future state process to drive requirements will increase scope stability. As you get deeper into the project life cycle and designing the solution, the learning and assimilation of your customers heightens. They begin to ask for new features and bring forth new ideas. The goal is not to shut down these requests; you actually want a healthy dialogue of new ideas from your customers. This means they are engaged! But first you have to go back to the process and determine whether these new ideas will change the process. If so, the future state must be updated and the impacts understood. If not, the ideas are adding to a wish list of feature creep. You must drive the discussion of how the requested feature will enhance the process. How much faster or accurate will it make your business, and at what cost?
Linking requirements to business process steps is the key. If a business process does not have specific requirements associated with it, then it must be a completely manual process with no system interaction. If the process steps include the use of the project’s product, such as a software application, then each requirement should have applicability to a process step. Otherwise, you have requirements that you can’t be sure are aligned with the project goals and can create expensive scope creep. To take this linkage a step further, consider continuing this traceability through testing. Testing focuses on ensuring that the business process is enhanced to achieve the desired benefits rather than just testing the features of the technology. This is what you want as a functional manager.
A business case demonstrates the strategic alignment and sense of urgency of the project, defines its scope, and shows the financial and operational benefits associated with the proposed project. It may also identify risks, identify and explain rejected alternative solutions, and identify resource requirements and monies needed to accomplish the project. Every business case is different. Your business case may have already been completed and approved. But if you are now just getting into the details of your current and future state processes, chances are you need to update the business case to make sure you realistically can achieve the benefits others have sold to management in the project approval process. Or, better yet, an update can identify additional benefits that management was not aware of. (Normally, updating is for the former, not the latter.) Your partnership must be able to know exactly where your benefits are coming from.
You may have done great work in creating solutions and rigorously evaluated the best options. But this solution still may not be worth implementing if you don’t have confidence in achieving the benefit rate your management desires. A cost/benefit analysis is a widely used technique for deciding whether to make a change. As a steward of your organization’s resources, you must continually validate that the benefit rate is attainable.
An important skill overall is to be financially aware. You and your project manager are the stewards of this project’s scarce resources. You must be able to identify if a project is in financial trouble or even kill a project that should have never been implemented.
Costs are either one-time expenditures or recurring expenses. Benefits are normally received over time. Benefits can be hard, meaning a true dollars savings, or soft, such as increasing customer satisfaction or reducing the risk of lawsuits. The simple cost/benefit comparison process is to understand the outlay of costs over time and the benefit stream over time, ultimately identifying the payback period or return on investment. Most organizations require a payback over a specified period of time, perhaps six months to two years.
When large sums of money are involved, cost/benefit analysis can become an extremely complex and sophisticated art. In such situations, partner with a finance expert who can help you document or update your cost/benefit analysis to meet the expectations of your management. The time value of money is usually an important calculation for projects of longer duration.
A simple example of the time value of money would look something like this:
Your call center project has been budgeted to cost $200,000 and will take one year to implement. You will incur $50,000 of annual costs associated with the new project over four years. You have created your current and future processes, identified process improvements, and calculated them to save $150,000 a year. Now your project office is looking at other projects that need to get done using the same resources. These projects (let’s assume they are comparable in size and duration) are expected to achieve 15 percent return on investment. So you need to do better than 15 percent, maybe 20 percent.
By doing simple math, you can see that your payback period is two years. Your project costs $200,000 and you net a benefit of $100,000 each year—$150,000 of benefits less $50,000 of operational costs. But is this a better return than the 15 percent return on investment of other projects competing for the same resources?
To answer that, you must factor in the time value of money. Money you have today will be worth more in the future; money can earn interest over time. In the worst case, your organization can invest the $200,000 in bonds that may return 3 or 4 percent. The other concept at work here is that benefits you receive in the future are worth less today because things generally cost more in the future due to inflation. Therefore, $50 of benefits you earn two years from now may only have $47 of purchasing power today. (This is why lotteries pay off winners with a discounted, one-time lump sum payment of their cash winnings rather than the full value.)
To determine if your project produces at least a 20 percent return, you need to discount those net future benefits by 20 percent per year. Your financial picture of your project in today’s dollars is shown in Figure 6-5.
Your net project benefit of $200,000 is worth only $58,873 when using a 20 percent return. Still, the project is very much worth pursuing.
Another project costs $1,000,000 and its duration is one year. You expect to receive $250,000 benefits for six years and incur additional operating costs of $50,000 per year. You need to achieve a 10 percent return. Is this a good project? This model is illustrated in Figure 6-6.
Figure 6-5 Sample Call Center Project Financial Analysis
By discounting future benefits by 10 percent over 5 years after your implementation (year 0), you still have not recouped the $1,000,000 project outlay. This is not a good project under these conditions.
The goal here is not to make you a financial wizard, but to help you become financially aware so you can understand how your project benefits are recognized and how they compare to your project expenditures. As you complete the initiating and planning processes, you should update these financial forecasts to reflect this new information. If your project costs have increased, consider what that does to your model. If you reduce scope and now have fewer benefits, what does that do to your model? Ultimately, the benefits should validate the project mission statement. Looking at the cost/benefit analysis, is the mission still viable, or does it need to change?
This information will be valuable to your project manager partner and will sustain the urgency behind your initiative. Connecting the need to the mission and telling a compelling story about where you are going and how benefits are created and measured creates momentum for project organization. These skills are critical for you, the functional manager, now that you are a vital component of your organization’s strategic change.
Figure 6-6 Sample Project 2 Financial Analysis
1. APM Group, “What is ITIL?” http://www.itil-officialsite.com/AboutITIL/WhatisITIL.aspx (accessed June 15, 2011).
2. The Ben Graham Corporation, “Process Mapping.” http://process-maps.com/ (accessed June 15, 2011).
3. Mike Walton, “What is DMAIC?” http://www.dmaictools.com/ (accessed June 21, 2011).
4. Aveta Business Institute, “The DMADV Methodology.” http://www.six sigmaonline.org/six-sigma-training-certification-information/articles/the-dmadv-methodology.html (accessed June 21, 2011).