Project Elaboration – Small Business Start-Up Strategy

In this module we take an example project component and, using its drivers, stepped through the process of project elaboration. We introduce the concept of objectives, deliverables, work steps and competencies (ODWC) to establish a method for translating an initiative into a detailed set of work steps. We then look at objectives to establish the different threads of work to create a work breakdown structure using the objectives to identify the deliverables needed.

Decomposing the Goals

We have all used top-down project planning to justify and develop rough-order-of-magnitude estimate for a project. However, a truly executable project plan requires bottom-up project planning and estimating, what we call project elaboration. Before we can successfully complete bottom-up project planning we must rigorously decompose the nature and strategic goals of a project.

Let's take an example initiative to develop a new order taking and shipping process. We are trying to get a SPEED advantage in the outbound logistics value chain link. See figure 1.

By doing this rationing of performance objectives to the departments critical to the achievement of the objectives, we can assess the reasonability of the performance objectives. We can also identify key stakeholders, i.e., the leadership of these departments, who should be involved in the vetting and commitment to this project.

The manager of the order-taking department might say, “I agree that the order taking time on an average order is about 45 minutes. However, my average salary is about $10 per hour, making a 45 minute order cost $7.50, not $6.00” If that is true then we must either add $1.50 to our total unit cost expectation or reduce, by $1.50 the cost estimates of either warehouse or shipping. In either case, the result is realistic expectations of performance objectives and, more importantly, commitment on the part of the involved stakeholders that the expectations are realistic and reasonable.

We may also discover if, for example, we cannot squeeze the extra $1.50 out of one of the other departments, that our new cost of $21.50 per order (the original $20 plus the added $1.50) is unacceptable, because it would cost us too much to get the speed advantage and therefore the project is not worth doing. We may also decide that the $21.50 is well worth the price for the speed advantage. The important thing is that we are making an informed decision, now. All of this discovered before we even start the project. There is an old saying:

“A wise man does first, what a fool does last.”

Sung Tsu, an ancient Chinese general, wrote principles of management. One such principle is applicable here:

“A battle is won or lost before it begins.”

Tactical Support Required

Sometimes an initiative will require tactical support of other value chain processes. For our example initiative of order taking and shipping, we might require support from sales and marketing to inform the customer of our new speed capability. If that is the case, we document the supporting processes and the nature of the support needed. The leadership of that processes would also be added to the stakeholder list and be included in the vetting of this initiative.

Project Drivers

We describe our project drivers, in terms of the project trinity (Cost, Schedule, and Performance). We describe each of the cost, schedule and performance measures for the project and which one will be optimized, which one will be constrained and which one we can accept.

For additional information on this, see "Constraint Reporting in Portfolio Management" by Mike Addario.

A critically important concept is that of project performance on a strategic project. The performance objective in a strategic project is always to build the process according to its trinity of unit cost, cycle time and throughput. The process's unit cost, cycle time throughput objectives become the performance measures for the project that is building it.

It is also important to note that, because of a strategic project's performance measure being the achievement of the process performance objectives, it is rare that a strategic project will not optimize performance (i.e., building the process right is an absolute necessity). There will be occasions where a strategic project, due to time-to-market considerations, will need to optimize schedule and constrain performance, but that should be the only time performance is not optimized on a strategic project.

For example, in our order-taking initiative, it is important that we “get it right” in terms of optimal process performance and cost. Because of that we are willing to invest time and money to do it right. However, we do need to get to market with it as soon as we can. So our project drivers will be described as:

Produce the process with the above performance objectives (OPTIMIZE performance, highest priority)
Get the process in production within 15 months (CONSTRAIN schedule, middle priority)
At a budget of $1 million (ACCEPT the cost, lowest priority)

We have made it clear what is driving our project, in no uncertain terms.

Elaboration

Let's review what we already know via the business case proof of concept.

The initiative's primary value chain mapping is the SPEED value creator, in the outbound logistics value chain link. Our process performance trinity is:

Cycle Time: 3 hours from take to Ship
Unit Cost: $20 per order from take to ship
Quality/Throughput: error rate less than 1% on normal orders.

We also know there are three major process/organizational components to this initiative: order taking, warehousing and shipping. During project initiation and vetting we obtained commitment from each of these three areas as to both the feasibility of the performance objectives as they relate to their individual area as well as the availability of key resources to devote to the project. In addition, we know the tactical support needed, for instance marketing, to let our customers know of our new speed capability, to make the project successful.

We know our project drivers:

Produce the process with the strategic performance objective (maximize)
Get the process in production within 15 months (constrain)
At a budget of $1 million (accept).

Let's review Figure 3. We can see that, in this project, we are maximizing performance. Our definition of performance is building the process that meets our cycle time, unit cost and quality/throughput measures. Because we are maximizing performance, as is often the case on strategic projects, we will accept no compromise on our project performance, as stated by our process objectives. Since schedule (15 months) is our second most important criterion, or constraint, we will not make any decisions that will delay the project unless there are no further options in our accept criteria: cost.

Breaking Down the Work

We already can see three obvious high-order breakdowns of work in the project plan: order taking, warehousing and shipping. It is now time for the project manager to engage “content experts,” people who know about these three areas of the firm.

Because of our business case proof of concept, and its inherent ability to assure commitment from the required organizational areas of the firm, the content experts have already been identified and have been committed to the project. In addition, due to the nature of a strategic project, people from Information Technology will likely be included in this planning meeting. The project manager facilitates a planning meeting with these the content experts and information technology. Each of these three experts will likely be a project lead for their respective areas of the project plan.

As the project manager brainstorms issues and work needed with these content experts, the following issues may come up:

Order taking: The old order taking information system is archaic and needs a complete rebuild. With that system change, every one of the order takers will have to be retrained, not just on the new system but also on good customer care skills. In addition, the phone system will need upgrading to interface with the new information system and balance the call load.
Warehousing: If we are going to be able to fill an order in under an hour, we will have to reconfigure the warehouse so the most used items are closer together. The warehouse is presently in SKU (part number) order. We need to be able to reconfigure the warehouse dynamically so picking tickets must be produced in warehouse location order not SKU order. The present inventory system is dated. We have had many instances, during periodic inventory counts, of incorrect quantities on hand in the perpetual inventory system. Because of this, our perpetual inventory system is considered unreliable. Our new order taking system depends on absolute accuracy in the perpetual inventory. Therefore, bar coding will be used to assure accurate inventory pulling.
Shipping: To assure accuracy in picking inventory and packing, bar code readers will be used to verify what gets put into each box. Packing lists and labels will be printed as the order is packed.
In addition, during this planning meeting, other issues might be identified. In addition to a phone ordering system, we need to develop a web-based online order system, which will interface directly to the new back office order processing system. As a result of this brainstorming, the project manager has identified five separate threads of work for this project:

Order taking thread: This will include creating the specification for the new order processing information system, selection and installation of the new phone system and all the training for order taking personnel. This thread has impact on process (new system), the people component (training and procedures), the knowledge component (new information system and new metrics to be used) and the technology component (new phone system and new computer system).
Web thread: This will include all web system development and its interface with the new order processing system. This thread impacts process (design of the online work flow for customer interface), knowledge component (interfaces to other systems) and technology component (web system development).
Warehouse thread: This thread includes the creation of the specification for the new inventory and warehousing system and designing the manual procedures for warehouse personnel. This impacts process (warehouse procedures), the knowledge component (information systems), the people component (retraining warehouse personnel on the new inventory pulling procedures) and the technology component (bar coding and scanning).
Shipping thread: This thread includes creating the information systems specifications to support the new packing and shipping procedures as well as the design of the procedures. This impacts process (new procedures), the knowledge component (training on new procedures to verify inventory during packing) and the technology component (dynamically producing packing lists based on what is scanned).
Information system thread: This includes the coordination of all information systems needs. This thread is the glue that binds the other threads together. It obviously impacts the technology component (new systems and technology) but it also impacts the knowledge component because all the other threads will be tied together via a comprehensive logical data model. This data model will house the knowledge needed by all the threads and provide the means for the products of each thread to communicate in the production system.

At this point the project manager has five well-defined quasi-independent threads of work. Because we have agreed that schedule (constrain) takes priority over cost (accept), the project manager will likely have a project lead for each thread. These five project leads will each plan, with the assistance of the project manager, their individual work threads. It is critical that each project lead be allowed to plan his / her individual thread. If the project manager “plans” it for them, two problems arise: 1) The project manager may not have as much content knowledge about that thread and 2) The project lead for that thread never takes “ownership” of his / her plan and therefore lacks commitment to it. Another Sung Tsu principle is applicable here:

“If you make a general responsible for the outcome of a battle, you must allow him to plan the battle. If you make him execute your battle plan, you are responsible for the outcome.”

If we want a project lead to take responsibility for the outcome of their thread, we must allow them to plan the thread. The project manager can and should lend advice, but the project lead should be allowed to plan the specifics of the thread, especially the estimates of the time needed to do the work. The annals of project management history are filled with the tales of project managers who “knew better” than their project leads and cut estimates on the leads' threads, only to have the actual time come out to be closer to the original estimate before the project manager cut it. If a project manager does not trust the estimates of a project lead, he needs to question whether that person should be the project lead on this thread.

The project manager can always question an estimate and the assumptions under which it was made and perhaps to convince the project lead that he/she is wrong. However, forcing the project lead to change estimates simply because you do not like the estimate or you think management won't accept it, is practicing wishful thinking in the extreme. What you are really saying is that the assumptions under which the estimate was made are sound but your boss isn't going to like it. So, by cutting the estimate arbitrarily, you are not estimating at all, you are wishing. In our experience wishes seldom come true in project management.

The project manager will align all the threads into a comprehensive project plan resolving any scheduling conflicts and co-dependent tasking among threads. Each project lead will be delegated responsibility for the day-to-day management of their respective thread. The project manager will also add required work steps, periodic reporting and other tasking necessary to overall project execution and control.

Decomposing a Thread

Let's take one thread, the Order Taking thread, as an example, and decompose it into a project plan component. To decompose anything into tasks in a project plan, we must use something we like to call the ODWC model.

ODWC stands for Objective, Deliverables, Work steps and Competencies. These are the steps we will go through to decompose this portion of the project plan. First, we list the objectives of this thread. They are:

Create a new order taking process
Create IT specifications for the new order taking system
Write procedures for the staff to use in the order taking process
Install a new phone system
Train the staff in the new system.

Now that we have these five objectives, we need to decide what deliverable or deliverables will demonstrate that we have achieved each objective. A deliverable is a tangible work product that demonstrates, either on its own or in conjunction with another deliverable, that an objective has been achieved. Let's take each objective and identify its deliverable or deliverables:

Create a new order taking process - This entails developing a logical process model and data model to describe the requirement of the process. So our deliverables would be a Logical Process Model and a Logical Data Model.
Create IT specifications for the new IT system - Once we have created the logical process model and logical data model, we need to make decisions about manual and automation boundaries. The portion of the process and data models that we choose to automate becomes the IT system. So the deliverables for this objective would be System Specifications and Data Base Design and then downstream a working tested, documented information system. So, additional deliverables would be: Tested Programs, a Populated Data Base and System Documentation.
Write procedures for the staff to use in the order taking process - The classic procedures manual is nothing more than the portion of that logical process model and logical data model that we have chosen not to automate. So, our deliverable for this objective is a Procedures Manual.
Install New phone system - Before we install a new phone system, we have to document our requirements for the new system, identify potential candidate systems for purchase and go through the process of weeding down the list to finalists and selecting a phone system to buy. The requirements would be a by-product again of our process and data models. So, our deliverables to support this objective are: Phone System Requirements Package, Candidate Systems List, Package Scoring Criteria, Finalists List, Selected Vendor and Purchase Contract.
Training the staff on the new system - For all of this to work properly, obviously the staff must be properly trained. Deliverable for this objective would include: Training Materials, Trainers Identified, Trainers Trained, Training Classes Scheduled and Conducted Training Classes.

Let's review what we have so far for the deliverables for this thread:

Logical Process Model
Logical Data Model
Systems Specification
Data Base Design
Tested Programs
Populated Database
System Documentation
Procedures Manual
Phone System Requirements Package
Candidate Systems List
Package scoring Criteria
Finalists List
Selected Vendor
Purchase Contract
Training Materials
Trainers Identified
Trainers Trained
Training Classes Scheduled
Conducted Training Classes

It is important to note that, for the sake of brevity, we did not include all the deliverables that would likely be needed for this project. For example, we included nothing concerning the conversion of the system data from the old system to the new one or other deliverables involving system cutover. From five objectives we identified, fairly quickly, nineteen deliverables. For each deliverable we now want to identify the specific work steps that it will take to produce that deliverable. Also, as we look at each deliverable we can identify opportunities for further delegation of responsibilities by making specific team members responsible for a given deliverable.

For example, the deliverable of Training Materials is one which, in order to identify the work steps required to produce it, would require some training expertise. Therefore, we might ask that someone from the training department be assigned to the project to assist in delineating the specific work steps, including time estimates, required to produce the training materials. We might also ask them to identify who in the organization would be qualified to develop them.

This is where the “C” in ODWC comes in. C means competencies. Once we identify the work steps needed we will have to resource or staff the work step. We need to find out who is competent to do the work. Until we identify the person who will do the work, and their level of competence, it is difficult to estimate the time to do the work. However, on many projects we have to do just that; we have to estimate a task without knowing who will do it.

Summary

In this article, we took an example project component and, using its drivers, stepped through the process of project elaboration. We discussed how we break down the project into the specific work required to complete it. We introduced the concept of ODWC, objectives, deliverables, work steps and competencies, to establish a method for translating an initiative into a detailed set of work steps. We showed how we look at objectives to establish the different threads of work and then create a work breakdown structure for that work using the objectives to identify the deliverables need. We then used the deliverable to construct the work steps.

About the Author

Dr. Landers holds a doctorate in strategy planning and has over 30 years of business systems experience. He co-founded or founded three consulting firms (all of which were successfully sold), and in addition to his executive responsibilities in these firms, directed the consulting and training activities.

Dr. Landers has achieved industry recognition through his presentations and publications and has established his reputation as a top-flight consultant through his work at Norveld Business Systems, Inc.