We need to be careful with this test objective because the targeted (really, at this point, estimated) completion date will appear in different documents depending on the project management methodology you' re utilizing. In a more rigorous methodology, the estimated completion date comes about as a result of cost- and time-estimating techniques that you apply to each task (I talk about this in much more detail in a later chapter). You would not put an estimated completion date in a more formal methodology' s scope doc; you' re too early in the process for that. Instead, in your project plan, you d supply not only the estimated completion date, but also the tasks, their durations, and their costs.
In a PACE-oriented environment, you can safely combine all this information into one document that represents the scope of the project. In this section of the scope document, you give a completion date, along with the rationale for how you arrived at this date. This is a calculated date derived from estimating, planning, and risk evaluation, including contingencies for identified risks. In actuality, you' l l simply plug in the date you arrived at from your project plan, which we' l l talk about later in the book. But suffice it to say that the completion date information also includes the way that you concluded what the date would be.
Warning Sometimes what drives the completion date is something other than just adding up the time required. The date might be driven by the project sponsor, a business need, a marketing strategy, a technological impetus, or simply because the CEO said "make go!" Always be well aware of what—or who— is driving the deadline.
You will probably decide to use the more rigorous PMI methodology for very large IT projects (Windows 2000 Server deployed across a large enterprise, for example) and usually not for smaller ones. This test objective talks about putting an estimated completion date into the scope document—implying that we're talking about a PACE-like methodology. (This is not to imply that you cannot use estimating techniques in a PACE-oriented document—so as to definitively detail task costs and schedules.) Some constraints have the ability to change the completion date. The Y2K problem was an example of a project that had a hard date. The project had to be coded, tested, and implemented no later than 12/31/1999 at 11:59 p.m. Budget restrictions might push your targeted completion date out much further than originally anticipated. Constraints can also exist in the form of industry regulations, governmental laws, rules, and regulations. For example, if you're managing a project that will bring forth a new pharmaceutical drug, part of your project deadline calculation is the speed with which the Food and Drug Administration (FDA) is able to test and approve the new drug. Your completion date depends on the elapsed time for all the necessary processes, not just your hoped-for deadline. You may want to get the drug onto store shelves in two years, but the FDA testing process might delay the introduction well beyond that.
Was this article helpful?
What you need to know about… Project Management Made Easy! Project management consists of more than just a large building project and can encompass small projects as well. No matter what the size of your project, you need to have some sort of project management. How you manage your project has everything to do with its outcome.