Project Charter Benefits
Make sure you state what the business benefits are going to be. While the charter needs to state what the new project is going to provide and make some general statements of what improvements might occur. You really need to state benefits in terms of the stakeholders and the organization. In real life your projects are going to be competing with other projects for approval and resources so you need to do your best to provide good clear benefits. You want management to read the charter and understand why it is important to the organization to do the project. You don't want them to read the charter and say, "So what?" "I don't see the benefit." "I see what you are trying to accomplish but I don't see how that benefits the organization."
…show more content…
"Why is your project more beneficial than building a new warehouse, or upgrading our manufacturing line, or buying 100 new police cars (I used to work for the Illinois State Police)?"
Preliminary Scope – This is your first opportunity to start defining the boundaries of your project. The scope statement is critical because it states what you are (are not) going to accomplish by doing the project. At this point you are early in the project but, it is still important to begin developing the scope statement as completely as possible with the information you have at the time. At this point the preliminary scope will help you develop your Project Charter. The preliminary scope will provide input to the Project Objectives and Success Criteria portions of the charter. As you get more information later, the scope will most likely change, which is okay early on in the project. You will, later on, halt changes to the scope. Once that occurs, it does not necessarily mean changes will not occur, but if they are going to occur they are going to have to go through a change management process.
Your scope is like the boundary around a sports playing field. Anything inside the boundary is in play (part of the project). Anything outside the boundary is out of play (not in the project). So just are boundaries on a playing field are easy to see and obvious, you need to develop your scope so what is part of the project is easy to see. You can accomplish this by being detailed and specific.
Project Management Plan – The Project Management plan will evolve as you go through the planning process. When you create your first version you are creating the foundation for your complete plan. As you go through the various knowledge areas, you will update the information in the plan and actually refer to documentation you will create later such as the scope statement, risk management plan, work breakdown structure, etc. This document also gives you a chance to lay out the ground rules for some of the administrative processes that will occur in the project (see managerial and technical processes section).
A key component of the Management and Technical Processes is the incorporation of the Deliverable Acceptance Form. This form is used to document whether or not each deliverable produced has been accepted or not and why or why not it was accepted. Having this key piece of documentation is essential for the team so they know whether or not they have completed a deliverable or if they need to continue to work on it to make it acceptable.
Scope Management Plan – This plan discusses scope creation, verification and maintenance. Once very key concept is the scope is not created by the project team alone. It must be a cooperative effort between the project team and stakeholders of the project. One key element related to project failure is the lack of involving stakeholders in the creation of the scope. After all, they will be the ones using the end product so it is critical that they are heavily involved in determining what the project is going to do. While this may sound obvious, it is a common mistake made by project teams.
Scope Statement - Your scope statement is one of the most critical documents you will create. It reflects the understanding between the project team and user as to exactly what will be produced by the project. And, including what will not be produced is also good especially, if there has been some issues concerning what will and will not be included. The more inclusive you can be here, the fewer conflicts you will have later.
Project Justification - focus on why are we doing this project and how is it going to benefit the organization. You need to make your case as to why the project is important and needed.
Project Characteristics and Requirements - here you describing what the product will be that you will deliver as a result of the project. This is what you are building, making, designing - Focus on the Project's Products are what you are actually going to produce or build or end up with to solve the project's business need. The products are part of the solution itself. You are communicating -- here's what we are going to create as a result of this project.
Project Deliverables - The Project's deliverables are things you are going to need to produce or create in order to successfully build the project's product. Some of the deliverables are project management related -- scope statement, wbs, change management plan, costs estimates, etc. You need these to successfully manage the project. Other deliverables will be more directly related to producing the product and could be information you need or things actually produced. For example if you are building a website one of the deliverables might be a customer survey indicating the services they would like to have via the website. Another deliverable might be a home page design or website navigation structure. You are describing - here's the stuff we are going to need or generate while building our product.
Project Success Factors - Here you need to describe how you will measure project success - you need to be specific - terms such as successful, faster, improved - are not specific enough. You need to be able to measure the result. You need to come up with as many measures as you can. Also if you are replacing an existing solution it is a good idea to benchmark the old solution - get measures as to how the old way performs. Then as part of your measures for the new solution you can compare to see if the new way is actually an improvement over the old way.
1. Objectives are clear and measurable.
2. Provide the conditions that affect the objective
3. Provide the measures of success - how do we know we have successfully met the objective. Success measures should relate to our stakeholders - i.e customers, owners, employees, ... Properly stating the objectives in measurable terms is critical to a project's success. These will provide you with the targets your team needs to reach. And, these must be agreed upon by both the team and stakeholders.
Work Breakdown Structure – The work breakdown structure is all the tasks you will need to accomplish to complete the project. Some tasks will be fairly high level while others will need to be decomposed into more and more elementary level tasks. This is not an easy job. One of the reasons is you have to include all tasks needed to get the job done. We are not used to doing this and if your project involves people telling you how they do processes, they find it difficult to define what they do in detail. Try this yourself. Write down and sequence all the tasks needed to go from where you are now to your car or front door. Now, follow your work breakdown structure for getting to your car or front door. Did you make it? Bet you walked into a wall or forgot to open a door or went the wrong way. I doubt you made it the first time. Now, if this work breakdown structure was your project, you would revise it based on the information you gathered when you tried to do it. Your first version of your WBS will most likely not be correct. You need to verify it by pretending to do it, reviewing it with stakeholders, reviewing it with others – whatever you need to do to get it right. Your work breakdown structure will eventually be entered into Microsoft Project and will serve as the basis for your schedule.
Schedule/Activity Sequencing
As you develop your resource and duration estimates (see below), this is also a good time to develop your successor and predecessor relationships. Essentially you have to figure out, for each activity, what activity has to be done before this activity can start and what activity depends on this activity before it can start. These relationships will determine the order in which the activities will appear and, will determine the critical path(s) in your project.
Is having slack or contingency time in a project an okay thing to do?
Personally I feel building in slack or extra time in a project is a good practice. This would be extra time set aside for unexpected circumstances. I actually like the term contingency time. Unexpected things will happen. People will get sick, emergencies will occur, a key member of the team will quit, an activity or two will take longer than you expected. Having contingency time in your project will help absorb these things. Notice that I did not say anything about doing extra work not included in the scope. I do not feel this is what this type of time should be used for. Additional work that expands the scope should go through the change process and if approved the scope, time, cost and the schedule should be adjusted accordingly. It is tempting to add a little piece of work here and there but – avoid doing …show more content…
it.
How much contingency time should you add and where should it be in the schedule? I would add as much as 20% if you can get away with it. I would not add it to each task (There is a theory that people will take whatever time is assigned to perform an activity – so if you add extra time to each activity it will be used up just getting the activity done.). I prefer a pool of contingency time at the end of major milestones and perhaps a bit more at the end of the project.
Note: For the Activity Resource Requirements and Activity Duration Requirements I suggest you combine the Activity Resource Requirements Information template with the Activity List and Attributes templates to create one deliverable for these two items.
Activity Resource Requirements – Here you are trying to determine what resources you will need to complete this task. This includes people on your team as well as other human and non-human resources. For example, to complete a particular activity, you may need someone from your team, a specialist, and a particular piece of equipment. This step is important because it determines what skills, types of workers, and other resources you will need. Sometime you can get the project done using your full-time assigned staff. But, often you will need specialists or a piece of equipment or software. By determining these resources now, you can help ensure the specialist is on board when you need them or the equipment or software is available when you need it.
Activity Duration Requirements – For this deliverable you are determining how long it will take to accomplish the activity. The book provides a number of ways to do this. You want to be as accurate as possible as this will determine one of your triple constraints – time. Key things to me are don't over commit your staff. Realistically no one works an 8 hour day. So develop your schedule based on something less. This will depend on your organization's standards, your staffing commitments, and staff talent among other things. I know in organizations in which I've worked, many staff members on a project had other obligations for which they were responsible. If they typically spend 20 hours a week doing this work and, they are not going to be relieved of this responsibility, then take into account that they will not be available for those 20 hours per week. One problem I have seen in many schedules deals with deliverable approvals. I often see in schedules that a date will be assigned for a deliverable to be due and delivered to a stakeholder for approval and that's it. You also need to include time for the stakeholder to review it -- put this in the schedule - if they have 5 days to review and get back to you then put that in the schedule and assign it to the stakeholder. Also, provide time in the schedule to rework the deliverable. Don't assume that just because you produced the deliverable it's going to be correct - make sure you put time in to revise it. This problem can be reduced by involving the stakeholder in the development of the deliverable. Stakeholder inclusion in the schedule. I suggest if you need something from any of your stakeholders - information, reviews, approvals, etc. Then put them and the task in the schedule. This lets them know what expectations you have from them and when they are going to occur. This will help them to plan their time and schedules so they can be involved when you need them.
Microsoft Project Entry of Schedule – Using the work breakdown structure and activity duration estimates you have developed, enter this information into Microsoft Project. Post the resulting .mpp file in your group’s Final Deliverables forum and title it “Microsoft Project Entry 1.”
Cost Estimates – Cost is the third component of the triple constraint and as such it is critical that cost estimates be as accurate as possible given the information at the time. At this point ideally you know what the desired scope is and you know the desired completion date. Your job now is to figure what the project is going to cost to complete all the work defined within the scope and get the work done on time, based on the desired delivery date. As the text explains, there are a number of ways to estimate costs. I agree with the author when she indicates more than one approach is good to use. If you have done the scope and time estimates first, your first cost estimate may be the first time your stakeholders find out what the project is really going to cost. More often than not the cost estimate is more than the stakeholders had budgeted. So essentially you most likely will enter a negotiation phase where you will deal with your triple constraints for scope, time and cost and hopefully come to an agreement of an appropriate scope that can be completed on time and for an amount of money the stakeholders can afford.
Quality Management Plan - One comment I typically give groups concerning this deliverable is to be specific in your quality measurements. Part of this deliverable is to determine what things will indicate your project is reaching the expected level of quality. What you want to stay away from are words such as good, fast, improved, high level ... You can't measure when you use words such as these. Your definition of fast may be different than your stakeholders. So, you need to try to identify something you can measure - instead of fast say something like less than 3 seconds. Instead of saying the house will have multiple bedrooms you say the house will have four bedrooms. You can measure these.
Really, each deliverable should have a defined and stated objective(s). Essentially, the deliverable objectives are part of your quality measure - does the deliverable do what it is supposed to do or not. Since you are looking for user/stakeholder signoff, you need to have clear criteria as to what the stakeholder is expecting from the deliverable. By specifying these objectives up front, your team knows what to aim for and what to produce. And, the stakeholder should be able to see that the deliverable provides what it is supposed to provide. Will stakeholders change their minds as to the objectives after they have seen the deliverable? Sure. If this happens, time to hit the Change Management process (presented later in the semester). Personally, I like to show stakeholders deliverables incrementally, this way they have a chance to change their mind before I get it all finished so I am changing a smaller piece than if I wait until I'm all done. Also remember keeping stakeholders highly engaged in the project is one of the best ways to help the project successful. If they are highly involved in defining and creating the deliverable, they are more likely to signoff on it the first or at least second time.
Responsibility Assignment Matrix – It is important that people know who is responsible for what during the course of a project. There will be a number of stakeholders involved with your project and each will play an important role. The responsibility assignment matrix is a good way to visually show what these roles are going to be. Stakeholders can get a good picture of what they are going to be responsible for and it informs the project team as to what to expect from each stakeholder. For example if stakeholder A is going to be responsible for defining the requirements of the project, using a tool like this informs both the person and the team of this role. Now, based on my past experience, you may get someone assigned to a role that they are not qualified for. For example, if stakeholder A is responsible for defining the requirements and you know that stakeholder A has little experience in the area they are defining, you need to question the assignment. As a project manager it is your responsibility to make sure the project is a success. Consequently, if you see someone has been put in a role they are not qualified for you need to try to get someone else. You will not always win but, you need to try. If you don’t win, then this would become one of your risks (see later).
Resource Histogram – the resource histogram provides a picture of when resources are going to be needed throughout the project and what resources will be used together. It provides the project manager, staff and stakeholders sort of a summary view of how resources will be loaded on the project.
Staffing Management Plan – As you complete your project you will most likely need people with different skills at different times. For example if you are building a house, you will need surveyors first, excavators second, concrete workers third, then perhaps a mix of carpenters, plumbers, electricians, and so on. You will not need all these skills at once or for the duration of the project but, you need these skills at specific times during the project. As such, it is important to know what skills you are going to need and when. Using this information, you can schedule the skills you need when you need them. Additionally, this allows the people you need to know when they are going to be needed on your project and can set their schedule accordingly or, tell you they are not available which allows you time to get someone else. If you didn’t do this type of deliverable you may need a certain skill (for example a carpenter) and someone with that skill may not be available. The result being the project is delayed.
Communication Management Plan – Good communications is a key to project success. Knowing this, it is important to specify what information is going to be provided to stakeholders, when it will be provided, and how it will be provided. This sets the expectations for the stakeholders so they know when to expect communications concerning the project and, expectations of the project team so they know when to produce information. One mistake I have seen (and done () is to hide bad news in the documentation that is sent to stakeholders (hoping they would not see it) rather than face the problem head on with the stakeholders. If you have a problem or issue that needs to be dealt with – deal with it. Go ahead and document it but also raise the issue with the stakeholders and work to resolve it. Just because you state that in the documentation that the project is late or over budget does not take away your responsibility to resolve it. This tends to be one of the more uncomfortable things for project managers to do but, it is something that you need to learn to do. The problem will not magically go away – it will most likely get worse if not resolved.
Microsoft Project Entry of Resources and Costs - Using the activity resource and cost estimates you have developed, enter this information into Microsoft Project. Post the resulting .mpp file in your group’s Final Deliverables forum and title it “Microsoft Project Entry 2.”
Risk Management Plan – A simplistic view of risk management is taking a look at your project (this is ongoing throughout the life of your project) and asking, “What can go wrong and, if it does, what are we going to do about it.” I know there are other factors such a probabilities of the risk occurring but many projects would go a long way just by asking this simple question. Things will happen that will jeopardize the success of your project. Unfortunately many project managers do not address the risks ahead of time and are surprised when something happens. By addressing risks in the planning stages, it gives you a chance to try to determine if something does go wrong what is my plan to get through it. It is guaranteed that things will go wrong no matter how well you plan. Just by planning well you improve your chances but, random acts of badness happen.
Risk Register – It is important that you document your risks and keep track of them on an ongoing basis. Some risks will go away while new ones will come up. For those risks you have identified, you need to perform some analysis and data gathering to fully document the risk. The risk register is your tool for doing this.
Procurement Management Plan – Most projects will require the purchase of something.
It could range from a small amount of supplies to hiring someone to complete the entire project for you. Most organizations have guidelines/policies for making purchases and you will need to comply with those policies. The procurement management plan will be used by the project team as a guide for making purchases or entering into contracts. Some purchases are easy – you need some supplies so you go to your authorized vendor and get them without any bidding processes. Other purchases require much more effort. One major mistake I have seen often when making these larger acquisitions is a failure to specify exactly what is needed. Be it the acquisition of a piece of construction equipment to hiring a consultant to do an information systems project, specifying exactly what is needed is a key component to actually getting what you want. Simply, if you don’t know what it is you need, how do you know when you have it? For example, if you wanted to buy a new cell phone you would most likely think about what you would want it to do before you went to the cell phone dealer. You might say to yourself, “What do I want to do with my cell phone?” Then you may make a list – I want to make calls, I want to take picture, I want to be able to send the pictures to my friends, I want to text message, I want to access the Internet, and so on. Then armed with this list (your requirements/what you need
in a cell phone) you would go to the cell phone store and say to the vendor, “I want a cell phone that does these things.” A project requires the same detailing of requirements (scope) before making acquisitions. Often times not having a good set of requirements will mean something is left out – something needed isn’t available. However, it can work the other way also. An electrical contractor here in Springfield spent $50,000 on software to run his business. He did no requirements so there was no scope for what the software should include. The package contained 5 modules (each could have been purchased for $10,000). After installation and working with the software for a few months he realized he only needed 2 of the 5 modules. Consequently he spent $30,000 he could have used for something else.
Another area of difficulty, which specifically relates to hiring of contractors, is contract management. Even though you have hired someone to do your project or part of your project, you need to make sure they do it correctly. A key to this is a good and specific scope. Remember, the scope defines exactly what is to be done. You cannot just let your contractor go out and do the job, you need to monitor the work.
Contract Statement of Work (SOW) - The Statement of Work is very important document as your project moves out of the planning stages and into actual implementation. The SOW which also gets incorporated into an RFP is essentially a detail identification of what the project should produce for the customer. The more detailed and specific you can be the better because you are going to be referring back to this to see if you are actually producing or if the contractor is actually producing what is expected. Also note that what is contained in the SOW must relate directly back to the Scope statement - in other words, everything in the SOW must fit within the scope and, there needs to be something in the SOW for every part of the scope. Actually, the SOW can be considered an internal contract and, when it is a part of an RFP is becomes part of the contract. And, as part of the contract, this is what the contractor (in-house or outsourced) is responsible for delivering. So, it is very important that this document is very clear, specific and detailed. Some RFP's I have been part of developing ended up to be hundreds of page long with the bulk being the specification of the work we wanted done (SOW). Be careful not to assume that things will be done or included in the project - this is the time to spell it out - if it's a feature that is needed - put it in writing.
Note – the Scope of Work section of the Contract Statement of Work on page 217 is not correct. The steps in the example relate more to preparing for sending out the contract request. What should appear in this section is your project’s scope (see discussion above).
Change Management Plan – Changes will occur as your project progresses. The important thing is to control changes. This is done with a change control system. Ideally, once we finalized the scope there would be no changes. Unfortunately, there will be. Once stakeholders start seeing deliverables (floor plan, mockups, product samples, etc.) they will sometimes change their mind as to what they want. This changing of the scope has been a long time problem for projects. Project managers and team members want to please the stakeholder and consequently agree to changes without analyzing the impact the change is going to have on the triple constraint (scope, time, and cost). Change can often make the resulting project better but, almost all changes will have an impact on the project. Basically, you can’t add another feature for free – there is going to be either or both a dollar cost involved as well as a time cost. What we want to do here is to present the impact of the change (cost and/or time) to the stakeholder and see if they are willing to incur the additional cost and/or time. If they are willing, we document the agreement as an accepted change and then redo the previous documentation (scope, budget, schedule, etc.) and move on. If not agreed upon, we do not do the change or delay it until the project is finished and perhaps implement it as a new project.
"Why is your project more beneficial than building a new warehouse, or upgrading our manufacturing line, or buying 100 new police cars (I used to work for the Illinois State Police)?"
Preliminary Scope – This is your first opportunity to start defining the boundaries of your project. The scope statement is critical because it states what you are (are not) going to accomplish by doing the project. At this point you are early in the project but, it is still important to begin developing the scope statement as completely as possible with the information you have at the time. At this point the preliminary scope will help you develop your Project Charter. The preliminary scope will provide input to the Project Objectives and Success Criteria portions of the charter. As you get more information later, the scope will most likely change, which is okay early on in the project. You will, later on, halt changes to the scope. Once that occurs, it does not necessarily mean changes will not occur, but if they are going to occur they are going to have to go through a change management process.
Your scope is like the boundary around a sports playing field. Anything inside the boundary is in play (part of the project). Anything outside the boundary is out of play (not in the project). So just are boundaries on a playing field are easy to see and obvious, you need to develop your scope so what is part of the project is easy to see. You can accomplish this by being detailed and specific.
Project Management Plan – The Project Management plan will evolve as you go through the planning process. When you create your first version you are creating the foundation for your complete plan. As you go through the various knowledge areas, you will update the information in the plan and actually refer to documentation you will create later such as the scope statement, risk management plan, work breakdown structure, etc. This document also gives you a chance to lay out the ground rules for some of the administrative processes that will occur in the project (see managerial and technical processes section).
A key component of the Management and Technical Processes is the incorporation of the Deliverable Acceptance Form. This form is used to document whether or not each deliverable produced has been accepted or not and why or why not it was accepted. Having this key piece of documentation is essential for the team so they know whether or not they have completed a deliverable or if they need to continue to work on it to make it acceptable.
Scope Management Plan – This plan discusses scope creation, verification and maintenance. Once very key concept is the scope is not created by the project team alone. It must be a cooperative effort between the project team and stakeholders of the project. One key element related to project failure is the lack of involving stakeholders in the creation of the scope. After all, they will be the ones using the end product so it is critical that they are heavily involved in determining what the project is going to do. While this may sound obvious, it is a common mistake made by project teams.
Scope Statement - Your scope statement is one of the most critical documents you will create. It reflects the understanding between the project team and user as to exactly what will be produced by the project. And, including what will not be produced is also good especially, if there has been some issues concerning what will and will not be included. The more inclusive you can be here, the fewer conflicts you will have later.
Project Justification - focus on why are we doing this project and how is it going to benefit the organization. You need to make your case as to why the project is important and needed.
Project Characteristics and Requirements - here you describing what the product will be that you will deliver as a result of the project. This is what you are building, making, designing - Focus on the Project's Products are what you are actually going to produce or build or end up with to solve the project's business need. The products are part of the solution itself. You are communicating -- here's what we are going to create as a result of this project.
Project Deliverables - The Project's deliverables are things you are going to need to produce or create in order to successfully build the project's product. Some of the deliverables are project management related -- scope statement, wbs, change management plan, costs estimates, etc. You need these to successfully manage the project. Other deliverables will be more directly related to producing the product and could be information you need or things actually produced. For example if you are building a website one of the deliverables might be a customer survey indicating the services they would like to have via the website. Another deliverable might be a home page design or website navigation structure. You are describing - here's the stuff we are going to need or generate while building our product.
Project Success Factors - Here you need to describe how you will measure project success - you need to be specific - terms such as successful, faster, improved - are not specific enough. You need to be able to measure the result. You need to come up with as many measures as you can. Also if you are replacing an existing solution it is a good idea to benchmark the old solution - get measures as to how the old way performs. Then as part of your measures for the new solution you can compare to see if the new way is actually an improvement over the old way.
1. Objectives are clear and measurable.
2. Provide the conditions that affect the objective
3. Provide the measures of success - how do we know we have successfully met the objective. Success measures should relate to our stakeholders - i.e customers, owners, employees, ... Properly stating the objectives in measurable terms is critical to a project's success. These will provide you with the targets your team needs to reach. And, these must be agreed upon by both the team and stakeholders.
Work Breakdown Structure – The work breakdown structure is all the tasks you will need to accomplish to complete the project. Some tasks will be fairly high level while others will need to be decomposed into more and more elementary level tasks. This is not an easy job. One of the reasons is you have to include all tasks needed to get the job done. We are not used to doing this and if your project involves people telling you how they do processes, they find it difficult to define what they do in detail. Try this yourself. Write down and sequence all the tasks needed to go from where you are now to your car or front door. Now, follow your work breakdown structure for getting to your car or front door. Did you make it? Bet you walked into a wall or forgot to open a door or went the wrong way. I doubt you made it the first time. Now, if this work breakdown structure was your project, you would revise it based on the information you gathered when you tried to do it. Your first version of your WBS will most likely not be correct. You need to verify it by pretending to do it, reviewing it with stakeholders, reviewing it with others – whatever you need to do to get it right. Your work breakdown structure will eventually be entered into Microsoft Project and will serve as the basis for your schedule.
Schedule/Activity Sequencing
As you develop your resource and duration estimates (see below), this is also a good time to develop your successor and predecessor relationships. Essentially you have to figure out, for each activity, what activity has to be done before this activity can start and what activity depends on this activity before it can start. These relationships will determine the order in which the activities will appear and, will determine the critical path(s) in your project.
Is having slack or contingency time in a project an okay thing to do?
Personally I feel building in slack or extra time in a project is a good practice. This would be extra time set aside for unexpected circumstances. I actually like the term contingency time. Unexpected things will happen. People will get sick, emergencies will occur, a key member of the team will quit, an activity or two will take longer than you expected. Having contingency time in your project will help absorb these things. Notice that I did not say anything about doing extra work not included in the scope. I do not feel this is what this type of time should be used for. Additional work that expands the scope should go through the change process and if approved the scope, time, cost and the schedule should be adjusted accordingly. It is tempting to add a little piece of work here and there but – avoid doing …show more content…
it.
How much contingency time should you add and where should it be in the schedule? I would add as much as 20% if you can get away with it. I would not add it to each task (There is a theory that people will take whatever time is assigned to perform an activity – so if you add extra time to each activity it will be used up just getting the activity done.). I prefer a pool of contingency time at the end of major milestones and perhaps a bit more at the end of the project.
Note: For the Activity Resource Requirements and Activity Duration Requirements I suggest you combine the Activity Resource Requirements Information template with the Activity List and Attributes templates to create one deliverable for these two items.
Activity Resource Requirements – Here you are trying to determine what resources you will need to complete this task. This includes people on your team as well as other human and non-human resources. For example, to complete a particular activity, you may need someone from your team, a specialist, and a particular piece of equipment. This step is important because it determines what skills, types of workers, and other resources you will need. Sometime you can get the project done using your full-time assigned staff. But, often you will need specialists or a piece of equipment or software. By determining these resources now, you can help ensure the specialist is on board when you need them or the equipment or software is available when you need it.
Activity Duration Requirements – For this deliverable you are determining how long it will take to accomplish the activity. The book provides a number of ways to do this. You want to be as accurate as possible as this will determine one of your triple constraints – time. Key things to me are don't over commit your staff. Realistically no one works an 8 hour day. So develop your schedule based on something less. This will depend on your organization's standards, your staffing commitments, and staff talent among other things. I know in organizations in which I've worked, many staff members on a project had other obligations for which they were responsible. If they typically spend 20 hours a week doing this work and, they are not going to be relieved of this responsibility, then take into account that they will not be available for those 20 hours per week. One problem I have seen in many schedules deals with deliverable approvals. I often see in schedules that a date will be assigned for a deliverable to be due and delivered to a stakeholder for approval and that's it. You also need to include time for the stakeholder to review it -- put this in the schedule - if they have 5 days to review and get back to you then put that in the schedule and assign it to the stakeholder. Also, provide time in the schedule to rework the deliverable. Don't assume that just because you produced the deliverable it's going to be correct - make sure you put time in to revise it. This problem can be reduced by involving the stakeholder in the development of the deliverable. Stakeholder inclusion in the schedule. I suggest if you need something from any of your stakeholders - information, reviews, approvals, etc. Then put them and the task in the schedule. This lets them know what expectations you have from them and when they are going to occur. This will help them to plan their time and schedules so they can be involved when you need them.
Microsoft Project Entry of Schedule – Using the work breakdown structure and activity duration estimates you have developed, enter this information into Microsoft Project. Post the resulting .mpp file in your group’s Final Deliverables forum and title it “Microsoft Project Entry 1.”
Cost Estimates – Cost is the third component of the triple constraint and as such it is critical that cost estimates be as accurate as possible given the information at the time. At this point ideally you know what the desired scope is and you know the desired completion date. Your job now is to figure what the project is going to cost to complete all the work defined within the scope and get the work done on time, based on the desired delivery date. As the text explains, there are a number of ways to estimate costs. I agree with the author when she indicates more than one approach is good to use. If you have done the scope and time estimates first, your first cost estimate may be the first time your stakeholders find out what the project is really going to cost. More often than not the cost estimate is more than the stakeholders had budgeted. So essentially you most likely will enter a negotiation phase where you will deal with your triple constraints for scope, time and cost and hopefully come to an agreement of an appropriate scope that can be completed on time and for an amount of money the stakeholders can afford.
Quality Management Plan - One comment I typically give groups concerning this deliverable is to be specific in your quality measurements. Part of this deliverable is to determine what things will indicate your project is reaching the expected level of quality. What you want to stay away from are words such as good, fast, improved, high level ... You can't measure when you use words such as these. Your definition of fast may be different than your stakeholders. So, you need to try to identify something you can measure - instead of fast say something like less than 3 seconds. Instead of saying the house will have multiple bedrooms you say the house will have four bedrooms. You can measure these.
Really, each deliverable should have a defined and stated objective(s). Essentially, the deliverable objectives are part of your quality measure - does the deliverable do what it is supposed to do or not. Since you are looking for user/stakeholder signoff, you need to have clear criteria as to what the stakeholder is expecting from the deliverable. By specifying these objectives up front, your team knows what to aim for and what to produce. And, the stakeholder should be able to see that the deliverable provides what it is supposed to provide. Will stakeholders change their minds as to the objectives after they have seen the deliverable? Sure. If this happens, time to hit the Change Management process (presented later in the semester). Personally, I like to show stakeholders deliverables incrementally, this way they have a chance to change their mind before I get it all finished so I am changing a smaller piece than if I wait until I'm all done. Also remember keeping stakeholders highly engaged in the project is one of the best ways to help the project successful. If they are highly involved in defining and creating the deliverable, they are more likely to signoff on it the first or at least second time.
Responsibility Assignment Matrix – It is important that people know who is responsible for what during the course of a project. There will be a number of stakeholders involved with your project and each will play an important role. The responsibility assignment matrix is a good way to visually show what these roles are going to be. Stakeholders can get a good picture of what they are going to be responsible for and it informs the project team as to what to expect from each stakeholder. For example if stakeholder A is going to be responsible for defining the requirements of the project, using a tool like this informs both the person and the team of this role. Now, based on my past experience, you may get someone assigned to a role that they are not qualified for. For example, if stakeholder A is responsible for defining the requirements and you know that stakeholder A has little experience in the area they are defining, you need to question the assignment. As a project manager it is your responsibility to make sure the project is a success. Consequently, if you see someone has been put in a role they are not qualified for you need to try to get someone else. You will not always win but, you need to try. If you don’t win, then this would become one of your risks (see later).
Resource Histogram – the resource histogram provides a picture of when resources are going to be needed throughout the project and what resources will be used together. It provides the project manager, staff and stakeholders sort of a summary view of how resources will be loaded on the project.
Staffing Management Plan – As you complete your project you will most likely need people with different skills at different times. For example if you are building a house, you will need surveyors first, excavators second, concrete workers third, then perhaps a mix of carpenters, plumbers, electricians, and so on. You will not need all these skills at once or for the duration of the project but, you need these skills at specific times during the project. As such, it is important to know what skills you are going to need and when. Using this information, you can schedule the skills you need when you need them. Additionally, this allows the people you need to know when they are going to be needed on your project and can set their schedule accordingly or, tell you they are not available which allows you time to get someone else. If you didn’t do this type of deliverable you may need a certain skill (for example a carpenter) and someone with that skill may not be available. The result being the project is delayed.
Communication Management Plan – Good communications is a key to project success. Knowing this, it is important to specify what information is going to be provided to stakeholders, when it will be provided, and how it will be provided. This sets the expectations for the stakeholders so they know when to expect communications concerning the project and, expectations of the project team so they know when to produce information. One mistake I have seen (and done () is to hide bad news in the documentation that is sent to stakeholders (hoping they would not see it) rather than face the problem head on with the stakeholders. If you have a problem or issue that needs to be dealt with – deal with it. Go ahead and document it but also raise the issue with the stakeholders and work to resolve it. Just because you state that in the documentation that the project is late or over budget does not take away your responsibility to resolve it. This tends to be one of the more uncomfortable things for project managers to do but, it is something that you need to learn to do. The problem will not magically go away – it will most likely get worse if not resolved.
Microsoft Project Entry of Resources and Costs - Using the activity resource and cost estimates you have developed, enter this information into Microsoft Project. Post the resulting .mpp file in your group’s Final Deliverables forum and title it “Microsoft Project Entry 2.”
Risk Management Plan – A simplistic view of risk management is taking a look at your project (this is ongoing throughout the life of your project) and asking, “What can go wrong and, if it does, what are we going to do about it.” I know there are other factors such a probabilities of the risk occurring but many projects would go a long way just by asking this simple question. Things will happen that will jeopardize the success of your project. Unfortunately many project managers do not address the risks ahead of time and are surprised when something happens. By addressing risks in the planning stages, it gives you a chance to try to determine if something does go wrong what is my plan to get through it. It is guaranteed that things will go wrong no matter how well you plan. Just by planning well you improve your chances but, random acts of badness happen.
Risk Register – It is important that you document your risks and keep track of them on an ongoing basis. Some risks will go away while new ones will come up. For those risks you have identified, you need to perform some analysis and data gathering to fully document the risk. The risk register is your tool for doing this.
Procurement Management Plan – Most projects will require the purchase of something.
It could range from a small amount of supplies to hiring someone to complete the entire project for you. Most organizations have guidelines/policies for making purchases and you will need to comply with those policies. The procurement management plan will be used by the project team as a guide for making purchases or entering into contracts. Some purchases are easy – you need some supplies so you go to your authorized vendor and get them without any bidding processes. Other purchases require much more effort. One major mistake I have seen often when making these larger acquisitions is a failure to specify exactly what is needed. Be it the acquisition of a piece of construction equipment to hiring a consultant to do an information systems project, specifying exactly what is needed is a key component to actually getting what you want. Simply, if you don’t know what it is you need, how do you know when you have it? For example, if you wanted to buy a new cell phone you would most likely think about what you would want it to do before you went to the cell phone dealer. You might say to yourself, “What do I want to do with my cell phone?” Then you may make a list – I want to make calls, I want to take picture, I want to be able to send the pictures to my friends, I want to text message, I want to access the Internet, and so on. Then armed with this list (your requirements/what you need
in a cell phone) you would go to the cell phone store and say to the vendor, “I want a cell phone that does these things.” A project requires the same detailing of requirements (scope) before making acquisitions. Often times not having a good set of requirements will mean something is left out – something needed isn’t available. However, it can work the other way also. An electrical contractor here in Springfield spent $50,000 on software to run his business. He did no requirements so there was no scope for what the software should include. The package contained 5 modules (each could have been purchased for $10,000). After installation and working with the software for a few months he realized he only needed 2 of the 5 modules. Consequently he spent $30,000 he could have used for something else.
Another area of difficulty, which specifically relates to hiring of contractors, is contract management. Even though you have hired someone to do your project or part of your project, you need to make sure they do it correctly. A key to this is a good and specific scope. Remember, the scope defines exactly what is to be done. You cannot just let your contractor go out and do the job, you need to monitor the work.
Contract Statement of Work (SOW) - The Statement of Work is very important document as your project moves out of the planning stages and into actual implementation. The SOW which also gets incorporated into an RFP is essentially a detail identification of what the project should produce for the customer. The more detailed and specific you can be the better because you are going to be referring back to this to see if you are actually producing or if the contractor is actually producing what is expected. Also note that what is contained in the SOW must relate directly back to the Scope statement - in other words, everything in the SOW must fit within the scope and, there needs to be something in the SOW for every part of the scope. Actually, the SOW can be considered an internal contract and, when it is a part of an RFP is becomes part of the contract. And, as part of the contract, this is what the contractor (in-house or outsourced) is responsible for delivering. So, it is very important that this document is very clear, specific and detailed. Some RFP's I have been part of developing ended up to be hundreds of page long with the bulk being the specification of the work we wanted done (SOW). Be careful not to assume that things will be done or included in the project - this is the time to spell it out - if it's a feature that is needed - put it in writing.
Note – the Scope of Work section of the Contract Statement of Work on page 217 is not correct. The steps in the example relate more to preparing for sending out the contract request. What should appear in this section is your project’s scope (see discussion above).
Change Management Plan – Changes will occur as your project progresses. The important thing is to control changes. This is done with a change control system. Ideally, once we finalized the scope there would be no changes. Unfortunately, there will be. Once stakeholders start seeing deliverables (floor plan, mockups, product samples, etc.) they will sometimes change their mind as to what they want. This changing of the scope has been a long time problem for projects. Project managers and team members want to please the stakeholder and consequently agree to changes without analyzing the impact the change is going to have on the triple constraint (scope, time, and cost). Change can often make the resulting project better but, almost all changes will have an impact on the project. Basically, you can’t add another feature for free – there is going to be either or both a dollar cost involved as well as a time cost. What we want to do here is to present the impact of the change (cost and/or time) to the stakeholder and see if they are willing to incur the additional cost and/or time. If they are willing, we document the agreement as an accepted change and then redo the previous documentation (scope, budget, schedule, etc.) and move on. If not agreed upon, we do not do the change or delay it until the project is finished and perhaps implement it as a new project.