5.6. Developing the Project Proposal Earlier in the chapter, we listed the ideal elements for a project proposal. If you were handed a proposal to validate or if you were developing one from scratch, you now should have enough preliminary information to develop your project proposal. Let's review the list one more time: Business case Financial analysis Market factors or requirements High-level scope and requirements Assumptions and exclusions High-level resources High-level schedule Success criteria Risks Alternatives Recommendations
In Chapter 2, we discussed the importance of aligning IT projects with corporate strategy and for making the business case for your projects. Here's where it comes into play. If after looking at the problem and desired outcome(s), if after listing all potential solutions and developing either a ranked list or a selected solution, if after all of that you can't make a business case for the project, you need to rethink your direction. Granted, you may not be in a position to change or cancel the project, but you will be in a position to discuss the potential problems with your project sponsor. Throughout this book, we'll continue to discuss ideal scenarios and best practices, not because we're unaware of the real world, but because we want to create an opportunity for you to grow and learn and hopefully create these best practices out there in the real world. In some cases, you need to get the project up, running, and completed in a very short amount of time. This can occur for numerous reasons, but typically it's because there is some opportunity that someone wants to capture before it goes away. While it's not an ideal situation, it's certainly common in the corporate world. If you're pressed to get a project underway very quickly or you know that certain data will be seen as extraneous, bothersome, or presenting it would be considered an act of insubordination, you can create an abbreviated project proposal. In those instances, you can instead create a project proposal that includes: Clearly, if you create an abbreviated proposal, you're missing the opportunity to ensure the project aligns with corporate strategy (the business case). You're also missing the opportunity to identify market requirements that might impact or influence the project. You're missing a lot of opportunities to clearly identify the project, but sometimes you just have to get the job done and do as you're told. If you aren't going to develop a full-fledged project proposal, make sure you at least cover the basics because this will be the foundation of the project as well as the basis for determining project success. As you read subsequent chapters of this book, you'll gain the skills to develop the remaining data for the project proposal. We'll discuss target schedule, resources, and budget in more detail. If you do not have all the information you need to develop a solid project proposal, especially the more thorough version listed earlier that includes business case and financial analysis among others, don't worry. In the next chapter, we're going to continue to develop our project plan and define some of these additional elements. In some companies, you're expected to justify the business case or show the cost/benefit of the project long before you've had a chance to develop project details. It's difficult to develop the project budget (which describes the cost of the project in the cost/benefit analysis) before you've defined all the work that has to go into the project. At the same time, you can't just expect to be handed a blank check for this yet-to-be defined project. So you have a bit of a dilemma. Let's take a minute to discuss estimating at this point in the project lifecycle. 5.6.1. Creating Estimates At this point in the project planning process, you really only have a wild guess about what the project will cost and how long it will take unless it's similar to projects you've done in the past. Therefore, any estimate you toss out at this point would really be a guess, so informal or ballpark estimates are usually a waste of time at best and potentially dangerous at worst. You can really tank your reputation by consistently tossing out bad estimates, so try to avoid this whenever possible. When you need to create a more formal estimate for your project proposal, you can do so in a number of ways. Again, your estimate will still be just thatan estimateuntil you actually break down the work into recognizable tasks (we'll do that in Chapter 9). The estimate you'll create at this point should get you closer to reality and will often be used as a go/no go decision point. 5.6.1.1. Elements of a Formal Estimate For an initial, high-level estimate, you should include three key elements: A list of assumptions that were used to create the estimate. This might include what is included and excluded and other assumptions that would impact scope, time, cost, or quality. A range of variance for the estimate. How far off could you reasonably be? Sometimes you're so uncertain that your variance might be 100%, other times you might be reasonably confident (especially if it's similar to another project you've done) and the variance might be as low as 20% or 30%. A time period for which the estimate is valid. Obviously, an estimate created today will likely be completely invalid in three or six months due to changes in technology, staffing, and market costs. Make sure you attach an expiration date to your estimate so it doesn't come back to haunt you eight months later.
5.6.1.2. Developing an Estimate If you have any historical data you can use in your estimating process, this is the best place to start. Historical data can help you not only determine costs more closely, but can also help you review variances and problems that impacted similar projects in the past. For instance, if a similar project was bogged down because it depended on one technical "guru" who is in constant demand and this current project requires the same resource, you'll need to either build in extra time to work around this expert's schedule or build in extra cost to hire an external expert. It's also important to understand that the closer you get to actually starting the project work itself, the more reliable your estimate will be. At each point in the project plan lifecycle, your confidence in estimates should increase. For example, at this point in the project planning process, your confidence in any estimates is (and should be) fairly low. Once you've fully developed functional and technical requirements for the project, your confidence in your revised estimates should increase significantly. Once you create the work breakdown structure (WBS) for your project, your revised estimate should become your target. It is at that point you will have to (and should) commit to your estimates and these become your goals or targets for the project. In some cases, it's impossible to know how long one phase of a project will take until you have more confidence in your estimates for an earlier phase. In larger projects, phased estimating is often used to continually refine the project estimates because as each phase is better defined, the confidence in those estimates increases and provides input data for later phase estimating. There are three commonly used methods of developing cost estimates that might be helpful for you: parametric, bottom-up and top-down. Parametric Estimates A parametric estimate uses the parameters of other, similar projects as the basis for the estimate. These often are broken down into recognizable units such as cost per unit or labor hours per unit. If you can determine, for instance, the prior cost per user and you know how many users you'll have in this project, you can determine the estimated total cost. If you also know the total time per user, you can multiply the number of users and the total time to determine the estimated schedule. This is most useful when you've done other similar projects in the recent past. Bottom-up Estimates Bottom-up estimating is the most time consuming method of estimating, but it is also the most accurate. The biggest problem with bottom-up estimating at this point in your project planning process is that you don't have enough detail to create a bottom-up estimate. In fact, you typically create a bottom-up estimate based on information developed from your WBS and you aren't ready to create your WBS yet. When you do develop estimates from your WBS data, you really will be closer to targets (what you'll be committed to achieving) rather than estimates. To create a bottom-up estimate, you figure out the time and cost for every project task (which is determined from the WBS, covered in Chapter 9) and add up it all up. Very accurate, very time-consuming, and not usually helpful for these early-stage estimates. Top-down Estimates Top-down estimates rely upon historical data from past projects, so if you've never done a similar project before, you cannot use top-down estimating. It starts with an estimate for the entire project then assigns a portion to each phase. For instance, you might start with a project total of $100,000 and estimate that, based on historical data, design is 10% of the total (cost), planning is 20%, and so forth. You could do this for time and cost estimates. This is not a particularly accurate estimating technique unless you are confident in the total cost of the project and you have historical data to help you determine the breakdown.
Enterprise 128 …
Elevator Estimates | Be very careful when asked for project estimates, whether you're riding in the elevator or passing in the hallways. "Elevator estimates" are almost always taken at face value; the word "estimate" seems to disappear and any estimate you gave becomes "fact." Suddenly, the number you casually tossed out to the executive pressing you for "just a ballpark estimate" becomes the target. To avoid this, prepare and practice a standard response such as, "We really haven't figured out an estimate yet, we're still trying to determine how much work needs to be done." If pressed, you may have to come up with a number but there's danger here too. Guesstimate too high and you could blow a perfectly good project right out of the water ("We can't afford to do that!"); guesstimate too low and you will more than likely be stuck with that estimate. In some cases, you can hedge your risk by saying, "Well, we've guessed that it's going to be around $80,000 and take about 14 weeks, but it could vary by 75% or more." Essentially, you've given yourself a lot of room by using the word "guess" instead of "estimate" (this often gets people's attention) and you also gave a possible variance of 75% (though this often isn't heard clearly). If at all possible, simply say, "We just don't know yet. I'll get back to you with an estimate." Remember that estimating is part science and part art and your skills will get better over time and with experience. |
Developing time estimates can be similar to cost estimates, though there are a few other concepts that will help you develop better time estimates. Effort versus Duration Some people get confused between effort and duration and it's vitally important to understand when creating time estimates. Effort is the actual amount of work required to complete a task. Duration is how long you'll allow for the completion of that task. Here's an example. You might know that it takes 1.5 hours to set up a new desktop computer for a user. However, you also know that your IT staff have many other tasks to complete during any given day. Rather than scheduling that task as a 1.5-hour task (we'll talk more about scheduling later in the book), you might give it a 1 day duration. That means that anytime within that day, the tech will have to find 1.5 hours to set up that desktop computer. Now, you might actually have that tech scheduled to do 14 other things that day, but setting up that computer must be completed during that 1-day time frame. That's a duration of 1 day for an effort of 1.5 hours. If you start scheduling for effort rather than duration, you'll find your schedule gets out of whack very quickly. The same goes for estimating. Use duration, based on your assumptions about effort, to build time estimates. First Time/First Use Penalty Remember the last time you tried to upgrade a software package or install a new server for the first time? It took far longer than subsequent upgrades or installations. There's always a first time/first use learning curve and this should be taken into account if you're working on a project that is unlike anything you've done in the past. While you may not be able to quantify this, you might be able to look back on other times you've had to do something for the first time and get a feel for how much extra time you should allow for a first time/first use type of project. Schedule versus Resource-Driven Projects Some projects are schedule-driven, meaning that the overriding constraint or "must have" is a final delivery date. Other projects are resource-driven, meaning the overriding constraint is the availability of resources. As you can probably tell, these two are fairly different types of projects. A schedule-driven project means it must be completed at a particular point in time and therefore you'll need to schedule resources in a way that gets the project done on time. Scheduling a resource-driven project means that you'll have to work around availability issues with various resources and this often means the project may take longer to complete. Understanding which it the overriding constraint on your IT project will help you develop better estimates. Milestones We'll discuss milestones in more detail later, but for the purposes of time estimating, they can be helpful if you know of any milestones in advance. For instance, you might estimate the time each phase of a project will take and create milestones for each phase. You might also have external constraints that will impact your project schedule and you may want to include those. If your project relies on a new version of a software application that is supposed to be released in May, you may set a milestone in May for that event. If the software application isn't released until July, that will delay your scheduled completion date. Milestones can help you look at the calendar with a mile-high view that can be helpful in determining high-level schedules and time estimates. You can also sometimes work your way backward from a particular milestone to get an idea of when something must start or be completed.
Cheat Sheet…
IT Project Proposals | There are many elements that may come into play in an IT project proposal. At this stage of the process, you want to stick to high-level elements such as the problem and mission statements, the proposed solution, the high level scope, and information related to how the IT project aligns with corporate and/or IT strategies. You probably don't have enough detail at this point to actually get into more detail, but if there are details you know you want to include in your project, you can mention them briefly in the project proposal or keep a separate document with these reminders so you can include them later in the project. Examples of items that might not belong in this initial project proposal that you'd want to include later might be critical user data or requirements, special factors related to resource cost or availability, a statement of work, or elements of a client contract. All of these things are important to the project, but unless they are critical for determining the initial project parameters (discussed throughout this chapter), you may want to keep things simple and not include them in the project proposal. If your company has a very formal project proposal process, all of these added details may be appropriate. |
Figure 5-7. Project Proposal 
| Applying Your Knowledge | Develop the project proposal. If you were handed a project proposal, you should now have most (if not all) of the data you need to validate that proposal. While there may be elements in the proposal, such as market data, that we did not specifically cover in this chapter, you can take time to validate those elements as well. If you were not handed a project proposal to start with, you now have some excellent data at your disposal for creating a thorough project proposal. Once this document is prepared, you should bring it to your project sponsor for approval. This is one of the first and most critical project checkpoints because misunderstandings here will multiply and become more expensive and more difficult to resolve later. |
|
