You won 't refer to executives unless they ' re specifically involved as project sponsor. You won't refer to team members by name—only by functionality.
Technical certifications may indeed be required for the project, but most likely not for the PM herself (though the IT Project+ certification would certainly be useful, wouldn' t it?). The scope document should detail the responsibilities and accountabilities the PM will have; the type of authority, whether informal or formal; the performance appraisal process; and, most important of all, the communications plan that will be used. The communications plan should include the type, purpose, recipients, and frequency of communication. It' s important to document the percentage of his time that the project manager is going to be able to give to the project.
The problem doesn't refer to e-mail as being required for the system, nor does it say anything about web pages being needed. However, there are two tacit personnel that aren't mentioned in the question, but are required: the server administrators and the business process experts. Typically, DBAs aren 't responsible for the servers that the Oracle databases run on—you need someone who understands the server network operating system (NOS) and hardware. The business process expert is needed to make sure that the project matches the business needs it is trying to meet.
There are two types of work matrices you' l l allude to when you develop your scope document: part-time matrix (your team members will be working part-time on the project and devoting the rest of their time to other work) and full-time matrix (where they' l l be working full-time on the project). If you have some folks devoted full-time to a project and some part-time, you have a mixed matrix.
Two important criteria that you have to develop are the landmarks that point to the success of the project, and the completion criteria—data that indicate the project is indeed complete.
Lessons learned is something that project team members don't typically want to include in the project book, because they' re afraid it may appear that mistakes were made. In actuality, mistakes were probably made—no one is perfect. And it' s important to note lessons learned, because if you encounter a project similar to this and refer back, perhaps you' l l pick up some pointers on what not to do. A
Something went wrong in the vendor negotiations and the timing of using the parts the vendor would supply. The project manager is responsible for predicting when the parts would be needed and negotiating accordingly with the vendor. (A purchasing arm of the company might well be the negotiator in such a situation, and the project manager might have very little control over the negotiations.) The point here is that the pricing agreed to on the vendor terms and conditions sheet didn' t agree with the timing of when the parts were actually going to be needed.
The tricky part here is that you might not need this resource. It' s just an ace in the hole for you. It is important that you receive acknowledgment from the authority who manages this resource, telling them that this possibility exists and gaining their participatory nod. The project sponsor also must know about the need. When the sponsor signs the scope document, they indicate they ' re aware that this outside resource may be necessary and that this has been communicated to the resource s managing authority. There s nothing automatically wrong with having a second sponsor in such a case as this. But remember that the more sponsors you appoint, the more room you leave for in-fighting, political rallying, bah-hum-bugging, and all that sort of stuff, people being people.
Even though the sponsor brought you the project, it is still necessary to perform good business analysis on the request and develop the project in such a way as to meet the needs expressed by both the project sponsor and the project client—in this case, the company' s customer. These two needs might be very different; the vice president simply wants heightened customer responsiveness, while the company' s customer wants a nice, easy interface that works
every time with no problems. Here is an example of differentiation of what you might at first consider a twin role, where the vice president was both the sponsor and a client. Not so: the company ' s customer is a project client.
Just how much of a quality problem there will be remains to be seen. However, we know that if time and budget are both short, the scope must adapt. The project sponsor and customer must be told that they can't have everything from soup to nuts with these kinds of strict requirements. A tight deadline is going to require exquisite communications between the sponsor, project manager, and customer. You probably don' t want this eventuality, but a tight budget will probably restrict the number of team members you' re allowed to have as well.
11. Optional Categories
Company terms and conditions and best practices life cycle might be things that you could omit from a small project' s scope document. Remember that Lessons Learned will be filled in after project completion.
The only leeway you have is the project ' s end date and the relative priority of the project. If the project needs to start immediately, but its end date is adjustable, perhaps you could continue to work on it as you have time—though this puts a damper on the team members that will be involved in the project. You could also assess the priority of the project and perhaps put it on the back burner until the first one completed.
The project sponsor won't affect the scope of the project; neither will the lessons learned. The end date, budget, and
completion criteria are just some examples of constraints that may well affect the scope of the project.
Scope creep is singularly controlled by the implementation of a detailed and enforced change-management program. The change- control features need to be documented in the scope document, which is subsequently signed-off by the project sponsor, giving you authority to say "NO!" to project additions.
The budget resources and success criteria will depend in large part on the request, company situation, and project priority. Doing some Web research to find out how others have handled projects like this will give you a very good feel for the time, budget, and resources you ll need in order to proceed. Lessons learned isn' t a constraint; it' s an outcome of a project.
Next in line is the review of the deliverables (acceptance testing) by the stakeholders. Once the stakeholders have approved the deliverables, the project sponsor can sign off on the review. Typically, documentation of the system can take place at the same time as the system is being developed. Lessons learned is documented near the end of the project, at project closure time.
The deliverable(s) will have to go through a software and hardware decomposition process, reducing the components down to their basic levels in order for you to be able to convey the complexity of the project. The project ' s end date, budget, and sponsor are affected by the way that the deliverables are described. Also directly affected in a project like this would also be the success and completion criteria.
Projects may or may not be required to utilize preexisting resources or personnel for their completion. Thus, this is a component that you may opt to leave out of the scope document if your project is a brand new one starting out with new personnel.
The customers must agree with the project requirements. The project sponsor must formally sign off on the scope document, thus approving the scope and nature of the work. It is the PM' s job to create a change control process, to review the deliverables as they ' re being created, to note the vendor s terms and conditions, and to develop a communications plan and a best practices life cycle. The PM figures out what the project' s priorities are, but does not order the project along with other corporate projects in priority order— that ' s a job for the sponsors and/or management.
You would first examine the request for viability. If you' ve already launched the project and the change is too large to take on at this late stage, then you say no to the change and go on with the project; you would have to have a second project to add on the new feature. However, if the change doesn' t significantly alter the project ' s requirements and can be safely worked into the project with little delay in time or increase in budget, then you go through the motions of documenting the change, evaluating its technical feasibilities with the development team, taking the change to the project sponsor, and obtaining formal approval to go forward with the addition to the scope of the project.
Was this article helpful?