6.5. Refining Project Parameters
So far, we've defined the initial project and gotten approval to proceed (Chapter 5). Then we took that initial project proposal and began to develop additional detail. At this point, you should have a list of three to five major deliverables or objectives. You should have identified and categorized your various stakeholders, and you should have an initial list of requirements. We'll continue to hone our project definition by refining the project parameters. A parameter is defined as "a fact or circumstance that restricts how something is done or what can be done." In this case, then, project parameters define what and how the project will be done. We'll discuss common project parameters used in IT projects in this section, but the list is not exhaustive. It's meant to cover the more commonly used elements, but you can certainly add to this list as your company and project requirements dictate. Our list is as follows:
6.5.1. Success Criteria
A study undertaken in the mid-1970's on project management showed that some projects meet their scope, time, cost, and quality metrics and are still considered failures. Other projects, by comparison, missed one or more of the scope, time, cost, or quality metrics and were considered successful. The study attempted to understand why this was the case. The results were published in 1974 and later summarized in a 1988 compilation [Baker, Murphy, Fisher "Factors Affecting Project Success" in Project Management Handbook, Cleland and King, Eds., New York: Van Nostrand Reinhold, 1988]. The findings can be summarized by this statement:
At first glance, you might think this all seems a bit obvious, but let's look a bit closer at this. If the project meets technical performance specifications and stakeholders (key people) are happy, the project is considered a success. This means that the project may have run over budget or past its deadline. It may have not included all the functionality (scope) or it may not meet all the technical specifications (quality). Still, it's considered a success. Ultimately, if the project meets the needs and/or expectations of key people, the project is considered a success. So, while IT project managers often spend a lot of time managing the project's metrics, especially time and cost, there's another element that, when well managed, can lead to the perception of a more successful project. As the study results and the summary statement demonstrate, success is, at least in part, a matter of perception. We've all experienced these kinds of things. For instance, if you bring your car in for repair and the people who greet you are courteous and efficient, you're more likely to think the car repair facility is a quality shop. You're not talking with the mechanics and finding out if they're certified or what type of experience they have to come up with your perception; you're basing it on how the greeter greeted you. Smart companies understand that first impressions create customer perceptions and that's the first place to begin managing perceptions of quality and service. The same is true in IT project management. You, as the IT project manager, are responsible for managing the perception of the project with key people. Certainly you are also responsible for managing the actual project's deliverables, but it should be clear that even if you deliver on all your requirements, the project may not be perceived as a success. Now that you understand that you must manage the project and the perception of the project, we'll talk specifically about success criteria. One way to manage project perceptions is through your communications, which we'll discuss in a later chapter.
22.214.171.124. Defining Success Criteria
Success criteria are the tangible criteria you'll use to define what a successful project is (and is not) and what it includes and excludes. The criteria from any and all of the stakeholders should include elements that address scope, cost, time, and quality whenever possible so that you can identify metrics for these four elements through your success criteria. The questions you can use to define these criteria are:
The influential stakeholders include other stakeholders on this list, but we're specifically talking about those who will utilize the results of this project. You gathered user requirements and can use these as a starting point for defining success criteria with the user. Work with them to develop specific criteria they'll use to determine the success of the project. To some of you, this may sound like we're defining acceptance criteria; they're not always the same thing and we'll discuss acceptance criteria in the next section.
You'll also need to work with your project sponsor to identify the success criteria he or she will use to determine if the project is a success. Typically the project sponsor will represent the business's objectives or priorities, but not always (which is why we'll also answer the next question in the list in a moment). As with your users, work with your project sponsor to define specific criteria he or she will use to determine whether or not your project is successful. If the project sponsor is very busy or not inclined to participate in this process, you'll have to proceed with caution. Although you may well be able to come up with a list of success criteria for your sponsor to review and approve, you run the risk of omitting some criteria that the sponsor ultimately uses but never reveals. If possible, have a discussion with the project sponsor to develop the success criteria and try to be as certain as possible that these actually are the criteria the project sponsor will use at the end of the project.
The success criteria used by corporate executives may or may not be the same as those used by the project sponsor. However, corporate executives are typically looking at the bigger picture, so the business case you made for this project will be helpful in developing the executive success criteria. Since corporate individuals are often the ones approving the budget expenditures for the project, they often have financial metrics by which they'll judge the success of the project. However, financial metrics are not the only metrics they may use. For instance, time to market or addressing a particular market niche might be part of their criteria. These may overlap with or even conflict with user success criteria, so you may have to do some negotiating.
Here's an example. If your project is to develop a software application add-on that addresses a particular need in the market, your users might say, "It will be successful if it includes the ability to generate reports quickly and easily." Based on initial research, you know that to do this will take a minimum of three months of development. Your corporate folks know that there is increasing competition in this market niche and want to get their foot in the door as soon as possible. In fact, they want the product out the door in 30 days and they don't really care if it can generate reports quickly and easily because they see that functionality as a secondary requirement. Now you, as the IT project manager, have to determine how to get everyone on the same page. You can't very well negotiate with the user group, which in this case is a new target set of users out in the world. You can't very well negotiate with the corporate folks who absolutely insist the project get out the door in 30 days. You may come up with some creative ideas, but one of the more obvious ones is to deliver the project in two parts and have your marketing folks make that clear to the market. For instance, you could deliver the initial set of functionality in the 30-day timeline and follow up with the reporting functionality within 60 days. While it might be possible to convince the corporate folks that they should wait 90 days and go in "with both feet" you might not win that battle. If you deliver in 30 days, the corporate folks might initially be happy, but will quickly realize that without the reporting functionality, the users are not happy. If you deliver in 90 days, the users may be pleased with the functionality, but your corporate folks will not only hound you for 60 days, but they may view the project as a failure. It's also possible that if you get the product out the door in 90 days, the market may have already been grabbed by your competitor, who got a competing product into the marketplace in 45 days.
The point is that you should not second-guess your target users or your corporate executives, but you may have to work to find a common area between two competing sets of demands. And ultimately, the corporate executives pay your salary, so if they say 30 days, that's what you're going to have to shoot for. Clearly, in this case we're talking about scope and timelines along with success criteria, but these things all come into play. If a project is delivered with reduced scope, it doesn't necessarily mean it will be perceived as a failure. If a project is delivered within scope, it doesn't necessarily mean it will be perceived as a success. Using the skills and talents you have as an IT project manager and those that you gained through understanding and applying material from earlier chapters (navigating politics, working with diverse groups of people, etc.), you should be able to define a common set of success criteria that will allow you and your project team to deliver a project that all key stakeholders define as successful. It might take some effort on your part, but defining these criteria now will help you make better decisions once the project is underway.
The last set of success criteria are those used by the IT project team itself. Talk with the project team (if you haven't yet defined your final project team, you may have to revise this list later) to define success criteria. Again, there may be many areas of overlap that correspond with user, project sponsor, or corporate success criteria, but there may be a few additional items to add to your list. You might think that the IT project team's success criteria don't really matter because they're not the users nor are they the sponsors of the project. However, their ability to perceive the project as a success is important to achieving final success because they must buy into the project and make the effort to achieve success. Remember the phrase we've used before: Projects don't fail, people do. If the IT project team can't define what success in this project means, they may not be as committed to it and therefore the overall success of the project may be in jeopardy. If the project team seems hard pressed to come up with success criteria, you may guide them toward using the requirements or the target scope, time, cost, and quality metrics as their success criteria.
6.5.2. Acceptance Criteria
Acceptance criteria are similar to success criteria, but are narrower in focus. They are typically used in technical projects though they can be used in many different kinds of projects. Acceptance criteria define the specific circumstances under which the user will accept the final output of the project. In external technical projects, the acceptance criteria are often contractual obligations and are typically captured in a Statement of Work document (discussed later in this chapter). The acceptance criteria are certainly related to success criteria because the end user will be influential in creating both.
Acceptance criteria should be specific, measurable, and binary. By binary, we mean that the answer is either yes or no, there is no "maybe." Either the criteria were met or not. This helps avoid ambiguity as well as the "yes, but…" issues that arise when trying to get a client to sign off on a project's deliverables. Clients typically refuse to sign off for one of two reasons: Either the project results really do not address their needs or they are not clear what their needs are (there is a third and very unfortunate reason some clients don't sign off and that's to avoid paying the bill, but we're talking about legitimate reasons here). By working to clearly define what it will take for them to sign off on the project's deliverables before you write one line of code or install one router, you'll be protecting yourself, your project team, and your company. If the client is internal, you'll be avoiding political maneuvering and miscommunication.
6.5.3. Scope, Cost, Time, and Quality
As we discussed in Chapter 1, scope is a function or result of the budget (cost), schedule (time), and quality (performance or adherence to specification). Different people describe this relationship using different analogies and they're all essentially saying the same thing. Some use a triangle whose legs are cost, time, and quality and the area of the triangle is scope. Others use the image of a stool where the three legs are cost, time, and quality and the seat of the stool is the scope. Whichever image or analogy works best for you is fine as long as you understand the relationship among these various elements. As you continue to refine your project, you'll need to continue to refine your estimates for scope, time, cost, and quality. When you finalize your project plan and present it to your project sponsor for approval prior to starting project work, you will have to commit to these metrics. As the IT project manager, you'll be held accountable for these elements and you'll have to manage the project in a manner that comes as close to delivering on all four elements as possible. However, remember that perception has as much to do with project success as does hitting your metrics, so spend time managing both metrics and perceptions when the project is underway. In Chapter 9, when you create your work breakdown structure (WBS), you'll gain a much clearer understanding of what it will take to complete this project. At that point, you'll be able to really clarify your scope, time, cost, and quality commitments for the project.
6.5.4. Flexibility Grid or List
As you're defining and refining your project proposal, you'll need to come to an understanding with your project sponsor about the nature of the relationship between the elements of the project including scope, cost, time, and quality. In this phase, you've refined your estimates on these four elements and are beginning to gather data that will ultimately help you pin down these four elements as part of your success criteria. However, we all know that when something goes wrong in the project, something's got to give. Using the image of a triangle whose area is the project's scope, if you expand the scope, one or more legs of the triangle will have to grow longer in order to keep the triangle a triangle. If you reduce the length of one of the legs of the triangle, the area of the triangle grows smaller. So, if the project's time or budget is reduced, something else has to "give" in order to keep the triangle in shape. This could mean that you reduce the quality and keep the scope relatively unchanged or you drastically reduce the scope. There are many different scenarios, but the point is simply this: things change and when they change, you need to know what your priorities are to manage the change in the best possible manner.
A flexibility grid or list can be used to describe how flexible any one of the elements is in the equation. The point is not to give you wiggle room on your commitments and deliverables, but to give you an agreed-upon priority list to use to manage change to the project.
To develop the flexibility grid, you should list the four elements: scope, cost, time, and quality. Then, with your project sponsor, decide which of these elements is least flexible. That means that when the going gets rough, this element should remain constant. If cost is the least flexible, it means that you should manage all elements of the project to keep the project within budget first and foremost. Does that mean you're going to ignore the schedule? Of course not, but if cost is least flexible, it might mean that rather than running several overtime shifts to make up for the (inevitable) project delays, you allow the project schedule to run longer or you put another project on hold to free up extra staff to work on the project. Knowing the cost is the most important, least flexible parameter helps you make decisions that support those priorities.
Each of the four elements should be rated: Least flexible to most flexible. You may use a numbering system such as 1 = Least flexible, 2= Less flexible, 3= Somewhat flexible, 4= Most flexible. Then, when you're working on setting your schedule, developing your budget, or deciding on your quality processes, you can make decisions that map with organizational and project sponsor priorities. Figure 6.7 shows a sample grid you can use for rating and recording the agreed-upon flexibility of each element. Remember, the project sponsor ideally is the one who ok's your flexibility grid because he or she is going to have to help you manage the perception of the project throughout its lifecycle and perhaps negotiate on your behalf with executives later on.
Figure 6-7. Flexibility Grid
Your flexibility list also comes in handy when you are deciding how much effort, or precision, each planning stage requires. Ideally, you should expend more effort (more precision or rigor) on those items that are least flexible because they are part of the project's constraints. If time is least flexible, you're going to expend more effort and be more precise in your scheduling than you might otherwise or you might expend more effort with scheduling than on budgeting if cost is most flexible. This flexibility list or grid helps both in your decision-making and your planning efforts. It helps avoid instances when your project sponsor becomes upset because you're running over budget when you assumed the schedule was more important. Clarifying these elements helps bring assumptions out into the open, and formal agreement as to the priorities of these elements will help you deliver a project that meets sponsor expectations and perceptions for success.
126.96.36.199. Precision or Rigor
The terms precision and rigor are often used in project management to indicate how precisely or how rigorously you will work on any particular step of project planning. This is directly related to flexibility, so it's included in this section. It stands to reason that if one element is least flexible, you must ensure that your project plan works around that element to make sure you deliver on that element, at the minimum. Certainly you want to deliver on all elements per your plan and agreements, but we all know that things change and when they change you need to know where to focus. If your IT project's budget is the least flexible element, then it stands to reason that you and your IT project team are going to be very precise when it comes to developing the budget. You're going to spend more time and effort ensuring the components of the budget are correct and that you can deliver on those commitments. If on that same IT project your schedule is most flexible, then you may choose to spend slightly less effort on developing a precise schedule than on developing your budget. At first you might balk and think, "Shouldn't I expend the effort to develop a highly accurate budget and schedule?"Yes, you certainly should generate accurate metrics for your project. However, if schedule is most flexible, it's highly likely that the schedule will change as the project progresses and all that time spent creating an incredibly detailed schedule will be wasted. This is one area in which rework can come into play. While you want to create a realistic schedule, if that's the element most likely to change, you may want to only develop a precise schedule for near-term work and develop a less precise schedule for work that comes later in the project.
Another element of precision or rigor is that if you're doing a project that is similar to one you've done many times, your level of precision or rigor may be less than if it's a brand-new project. You don't need to expend as much time or effort on planning a project in which many of the variables are actually known. Conversely, if you're doing a brand-new type of project, one in which none of your IT team has any previous experience, you will need to plan with far more precision (and probably also allow for more contingencies). Take, for example, the software company that installs its enterprise product at new clients. The project team that is responsible for client installations will develop a project plan for that client's installation. However, because this type of project has been undertaken many times in the past, there are not defined processes that will be used and the number of unknowns is relatively small. You might argue that client installation is a process, not a project. However, each client environment is new and unique and the definition of a project is that it solves a unique problem. Thus, it falls into the project category even though it relies upon many standardized processes. This is a situation in which your level of precision and planning may be relatively "low" except for the areas that are unique to the client.
There are no hard and fast rules about the level of precision or rigor in your planning processes except to note that the less flexible an element is, the more precise the planning must be and the more unknown an element is, the more rigorous the planning should be. With time and experience, you'll gain a strong sense of which parts of the plan should be precisely planned and at what point. The point is to avoid over-engineering parts of the plan and to reduce the amount of "wasted" effort and rework later on wherever possible.
6.5.5. Constraints and Limitations
We're still in the high-level defining and organizing phase of our project, so we're not going to dig into detail on constraints and limitations at this time. However, there may be some known constraints or limitations that you want to note in the initial project plan. These constraints and limitations might be quite relevant to your project sponsor and might be critical in a go/no go decision. For instance, if a constraint is that your IT staff is in the midst of a mission-critical project and key members of the IT team will not be available for additional project work for some time to come, the project sponsor may decide that this new project should be put on hold, cancelled, or outsourced.
Another example is if you're going to have to rewire part of your building as part of the project and one of your stakeholders mentions that the company is hosting several key clients for a week at some point during the project. You'll probably want to keep this in mind as you move forward and note it as a high-level limitation. These limitations and constraints will ultimately be tied to the tasks related to rewiring the building, and they could have a huge impact on the project's timeline (and perhaps budget as well), particularly if they are not built into the project plan. Again, avoid delving into tremendous detail at this point, but do make use of the opportunity to make note of any relevant constraints or limitations you're aware of going into the project.
As with constraints and limitations, it's also important to note risks to the project that you're aware of at this stage. Project risks can include internal and external risks such as changing market demands, changing technology, changing personnel, changing corporate priorities, and more. We'll spend time later in our planning process identifying risks and coming up with strategies to deal with these risks. For now, you simply want to identify those risks about which you're already aware. Again, these may be highly relevant to the project sponsor who might decide that these early risks are too significant to even continue in the planning process. While few IT project managers want to spend time defining and organizing a project and have it cancelled, now's the time to do it if it's going to happen. And if the project is cancelled for good reason, you can feel good that you did your job, which is defining the project well enough that others (project sponsor, corporate executives) can make intelligent, informed decisions about the project before project work gets underway.
Milestones are checkpoints set throughout the project to help monitor project progress. They are, by definition, zero duration tasks (a task in the project plan that is set to 0 days) in the project plan. They can be used for a number of different reasons. For instance, milestones can be used to indicate a point at which you check on the status of one phase of the project or to indicate the point at which external resources or deliverables must be received or to indicate the point at which you need to get project sponsor approval. We'll develop milestones in our project later, but there may be some high-level milestones you want to make a note of at this time so they are not overlooked later. You should be able to define the final milestone at this point, as it determines when the project is finished and has accomplished all of its objectives. Further planning may mean the project finish date moves, but you should have some idea of what that will be at this point in time.
Many people use milestones to indicate key deliverables. If that's how you and your IT project team use the term, that's fine as long as everyone has the same understanding of the definition of the word. Milestones that might be defined at this point are the deadlines for each of the major deliverables or objectives for your project. While these may not be known at this point, there are times when milestones can be set for the project during this phase. This will help you avoid missing them later when you get into the details of planning. You can also create milestones without exact dates to indicate major deliverables or events and assign specific dates to them later. For instance, you might create a milestone for development work, another milestone for testing, another milestone for quality assurance, and a final milestone for delivery to the client. These dates may not be known, but they are major markers in your project plan and if they are known at this point, they can be added.
6.5.8. Statement of Work or Project Charter
It seems that every project management system uses slightly different terminology, so you might find that your company or your clients or vendors use terms like Statement of Work or Project Charter to describe what we're calling the Initial Project Proposal. Whatever you want to call it, you should have a document that captures all of the work you've done thus far on the project. This document captures the high-level details of the project including the problem to be solved, the mission, the selected solution, the major deliverables (objectives), and the initial estimate for scope, time, cost, and quality. The document should also contain the project requirements as well as the success criteria and the acceptance criteria. Remember, all project management (including IT project management) is an iterative process, so you may have to go back through some or all of these elements as you learn more about the project. Each time you go back you should be refining more than changing the elements. If you find you're changing things rather than adding layers of additional detail, it should cause you to stop for a moment and ask why things are changing. If they are legitimate changes based on a greater understanding of the project, that's fine, but if things are changing because key elements have changed, you're aiming at a moving target and your project is at risk. If things are changing at this point, either the project environment (internal or external) has changed or you may have to spend time going back through the definition phase to really nail down the initial project statements (problem, mission, etc.).
The Statement of Work (SOW), Project Charter (PC) or Initial Project Proposal (IPP) all capture the definition and initial organization of the project. This type of document is typically used as a checkpoint to ensure the project is the right project at the right time for the right reasons. Many IT project managers set a milestone in their planning for both the development of the SOW, PC, or IPP and another milestone for the approval of the document. Once the document (SOW, PC, IPP) is approved, you have essentially entered into a contractual obligation.
You might be thinking that at this point you don't have enough information to agree to scope, time, cost, and quality metrics and you'd be right. At this point in the process, you're looking at high-level items. You should have enough information based on the requirements and success criteria to determine the project's scope. While you may develop additional detail about the elements that comprise the scope of work, it shouldn't change significantly after this point unless you've missed a major chunk of work. However, you can't reasonably know the schedule, cost, or quality until you get further into the project. You should be able to provide target estimates at this point (see Chapter 5 for estimating techniques) and most managers would expect that. For instance, you may be able to determine, based on the requirements, that the project will take about 6 months. You can estimate this based on similar projects you've done in the past. You might also know that you could be wrong by a couple of months since you don't have all the detail available yet. The data to include in the SOW, PC, or IPP should indicate thatyou could state that the initial estimate is 6 months with a margin of error of 30%. Some managers may want you to lock down these numbers at this point (and if you're working with a client, they may also press for this), but until you have more information about the project, it's hard to make a more precise estimate and you'll have to use your business savvy to explain why a more precise number cannot be guaranteed at this point.
When you've finished listing, defining, gathering, and defining all relevant project parameters, they should be incorporated into your project plan. It's a good idea to run these by your stakeholders (if appropriate) and your project sponsor for a formal review. Doing so helps you avoid omitting important data that will help your project succeed. Figure 6.8 shows the document developed as a result of this part organizing your project.
Figure 6-8. Project Parameters