The struggle to end a project
Darren Dambly Executive Consultant Autodesk, Inc 7935 E. Prentice Ave., Suite 400W Greenwood Village, CO 80111 Telephone: 303.256.5921, Fax: 303.256.5950 Email: darren.dambly@autodesk.com Abstract A Project has a beginning and an end by definition. But you can always add another feature to a software application. So, where do you stop one project and start a new project? It is critical for a project to have a clearly defined closure, otherwise it continues on a never-ending journey. Project sponsors are looking for short-term successes to secure ongoing support for the project. Also, as time goes on more complications are introduced such as changing technology and the departure of staff. Based upon the experience of specific projects, this paper will provide insights on how projects can be defined, structured and controlled to meet specific business functions. The pros and cons will be compared for Fixed Price versus T&M contracts with vendors. When to use each and how to combine the two approaches will be discussed. The comparison will consider both the customer’s and the vendor’s perspective. Tracking the project is critical for estimating how close you are to the end. Focusing only on certain measurements can give a false illusion. A variety of measurements will be discussed to provide a complete picture of the development status. Also, techniques in configuration and change management will be reviewed. Introduction Starting a project is relatively easy. Finishing a project is the challenge. Successfully finishing a project is an even bigger challenge. Every project can be a success or a failure. As many people claim, the outcome mostly depends on the people involved, not necessarily on the technology. The team’s decisions and direction over the course of the project is critical to its success. Also critical to success is avoiding the many traps along the way. This paper will focus on how the structure of contracts and change requests can be obstacles in the completion of a project, and how you can sidestep those obstacles. A major assumption of this presentation is that you (i.e., the customer) will be hiring external resources (i.e., vendors) to do various parts of the work for implementing your GIS. Your relationship with these vendors will have a large impact on the outcome of the project. Contracts are a tool for managing relationships with your vendors. Contracts define how you and your vendor will play together. Completing the contract correlates to the completion of the project, which is the true goal. But as one former employer said, “I’ve never seen a contract that can’t be broken.” How the “spirit” of the contract is executed is the people side of the relationship. Obviously, contracts can be used for or against you. So what type of contract should you use? How does it impact your ability to end the project? Defining a project A major step of any GIS project is to define an implementation plan, the roadmap of how the system will be developed and deployed. A number of technical and political challenges must be addressed as you define the implementation plan. What will the scope of the project be? Which users will be considered? How much functionality and data will be included in the initial release? How big or how small should the project be? Too big and the project becomes complex and risk increases. Too small and the project may not be feasible and and thus may not be supported. In addition, the scope of the project needs to be balanced with how much money and resources you believe you can ask for. Even if your cost/benefit study shows a fantastic return on investment, there will be a pain threshold (i.e., dollar level) that the sponsoring executive will be willing to request in the budget. The wasteland of previous “big bang” projects has made many executives reluctant to endorse large IS projects. Once the implementation plan is defined and the baseline established, you are ready to start staffing the project. You may decide to develop the system using mostly internal staff and augment your staff with specialized contractors. Or you may decide to contract out major portions, such as the data conversion or application development, to a vendor. Or you may hire a single vendor to provide a turnkey solution. Whichever option you select is fine. The common thread between all of these options that you must address is that you will need to sign a contract with the vendor. Services contracts - Fixed price versus T&M There are two basic types of services contracts—fixed price and time and material (T&M). Both types of contracts can work well and both can cause you misery. One key rule to remember is “how you pay people is how you motivate them.” Generally, fixed price means the vendor will provide a predefined deliverable (e.g., an application, a set of converted data, etc.) based on a set of specified requirements for a fixed amount of money within a certain time period. The vendor typically controls how the work is completed or the exact staff involved. The customer is charged the fixed amount regardless of whether the vendor spends more or less time to provide the deliverable. “Starting with the end in mind” is one of Stephen Covey’s famous sayings. The key to a successful fixed price contract is to have clearly defined requirements by which the vendor will estimate the work effort (i.e., price). Fixed price contracts also work best when there are well defined acceptance criteria. However, some changes to the requirements can always be expected. These changes are controlled via a change request approval process. We’ll discuss how change requests can impact ending your project later in this paper. T&M contracts are structured for you to pay by the hour or day for individuals provided by the vendor. Typically, the vendor will provide a list of available staff by skill levels and related daily cost rates. A general description of the type of work may be provided along with an estimate or a maximum amount of work effort required. The work of the contracted staff can be directed either by you or by the vendor. You are charged for only the hours worked by the vendor. T&M contracts are most effective when requirements are not clear, and, therefore, the work effort is difficult to estimate. An example could be the prototyping stage of a project. You can control when enough prototyping has been done and can stop work at any time. This contract type is commonly used when you are managing or staffing a majority of the work. Vendor staff can be hired in a staff augmentation role on a T&M basis. Customer Viewpoint The fixed price approach greatly reduces budgetary risks and sets a target date for project completion. Budget overruns may still occur due to change requests to the requirements. The greatest risk on a fixed price contract tends to be schedule overruns. Penalties can be included for schedule slippages, but this still does not guarantee an on-time delivery. T&M contracts are best suited if you plan on managing or doing a majority of the work yourself. You can then hire contractors as staff augmentation. T&M places all of the risks on you; however, you can release contractors as desired. Also, you may realize savings if the work is done sooner. Vendor Viewpoint Fixed price contracts present vendors with the greatest risk. Usually, requirements are not well defined during the bidding process, but you as the customer want a fixed price bid. Vendors must interpret the requirements and estimate the related work effort. To protect themselves, vendors add contingency amounts to account for unforeseen details. Also, language (usually listed as assumptions) is added in the proposal to provide the vendor with controls to help manage the unknown factors. The risk to the vendor is that the cost of providing the deliverable may be greater than the fixed price, resulting in a financial loss. However, advances in methods or technology may provide the vendor with the opportunity to increase the profit margin originally targeted. T&M contracts take the risk of losing money off the vendor. However, it limits their profit margin to precisely the difference between the billing rate and staff costs. Given a choice, most vendors would prefer a combination of the two approaches— having a defined, fixed scope of work and then performing the work on a T&M basis. If life were only this simple. The contract motivation traps Fixed price contracts can be the toughest to end because they place you and the vendor in a natural point of contention. You want the most for your money and you control signing the final acceptance certificate. There is little motivation for you to end the project by signing the final acceptance certificate until you are completely satisfied with the end product. Signing an acceptance certificate is more an emotional struggle than a logical one for most people. Final acceptance releases the vendor from the control that you’ve had over them for several months. Even with the guarantee of a warranty period, you wonder what might break or fail in the system just after you sign off on the final delivery. It’s like that feeling when you drive your new car off the dealer’s lot and realize it just depreciated by 30%, and then you rear-end the truck in front of you at the first stop light. You soon realize that all of the responsibility is yours. On the other hand, the vendor wants to complete the fixed price project with the least amount of effort so that they can maximize their profit. However, the vendor also wants to have you as a satisfied customer who will be a future reference. The good part is your vendor is pushing hard to complete the project. The potential bad part is that they’re not motivated to do any extras or any more than they need to. A T&M contract motivates you to end the project as quickly as possible. The vendor is not necessarily motivated to end a T&M project. As soon as the T&M project is completed, the vendor must find another project to earn income. As they say, a bird in the hand is better than two in the bush. Change requests – The never-ending story Every customer and every vendor learns something over the duration of a project. Change requests are the mechanism for modifying a fixed price contract to incorporate the new knowledge. Many times these changes are beneficial because they make the system better suit your needs. One trap you need to remember is that change requests cost your project time and money even if the change is never made. Most people severely underestimate the true costs of a change request. The moment you suggest a change to the vendor there is time spent managing the request. On one large project with several staff, the vendor charged the customer 16 hours of labor just for submitting a change request. This may seem unreasonable, but it’s not. A change request discussed for 15 minutes in a development team meeting consisting of 12 people equals three hours of labor. You can stretch out a project merely by submitting a number of change requests to be considered. Most vendors will allow you to submit a change request for no fee. They will then provide a time estimate and fee to assess the change request. The assessment will then provide a time estimate and fee to actually perform the change request. The biggest debate and hidden cost regarding change requests is the schedule impact. The work effort is relatively easy to estimate. But how do you assess the schedule impact of a single change on a project involving many people? How does the change affect the critical path? The exact amount is always debatable, but what we do know is that every change request, even ones just considered, distracts the entire team to some extent. Let’s look at an example of a small change request requiring two hours to assess and eight hours to perform—a total labor cost of ten hours. At a rate of $200/hour that equals $2,000. Now, consider that the change request was probably discussed in about four different status meetings for a duration of 15 minutes each. That pushes the entire project out by only one hour. A project with a team of 12 people at $200 per hour costs $2,400 per hour. Therefore, the cost of extending the project by one hour is greater than the actual work to perform the change. When you extend the project, the cost includes everyone working on the project. This amount is can be very significant. Another trap with change requests is the desire to constantly improve your project. Just accept it – you can always improve something. That’s why products have multiple releases. A struggle for many people is to decide when to stop development and deploy—when is good enough, good enough? Change requests are important for fine-tuning a project. Too many change requests can cause death by a thousand paper cuts. Controlling change requests is critical if you ever hope to end your project. Recommendations Fixed price contracts are by far the most popular approach for GIS development. It gives you the best protection. However, you may want a fixed estimate for the entire system well before sufficient detail is available. My recommendation is to utilize incremental fixed price task orders based upon a master agreement contract. Vendors can usually provide you with a good ballpark estimate for the entire system at the beginning of the project. But this is just an estimate. It’s better to break down the project into a series of fixed price steps. Using a waterfall development approach, a fixed price can be established for the detailed requirements step. Based upon the outcome of the requirements, a fixed price can be established for the technical design step. Next, a fixed price can be set for the actual delivery step. A rapid application development (RAD) project can be broken down into specific functional components or cycles. You may express concern with this approach because you fear the vendor will just keep raising the prices as each step progresses. You’re afraid of being trapped by the vendor. My responses to these concerns are the following:
If you elect the T&M approach, I strongly recommend that you develop your own staff to replace the contracted staff prior to the end of the project. You should plan to use only internal staff by the 75% completion point. You may still have some vendor staff onboard at the end of the project, but they should not be on critical tasks. These approaches should help both you, the customer, and your vendor to successfully end your project. | ||
|
|