Project Management

Linkedin Profile

Check out my Linkdin Profile at!  I’d love to hear your comments on what services you would like provided.



June 11, 2009 Posted by | Business Analyst, Living Your Best Life, Outsourcing, Phase Review Process, PMBOK, PMI, PMO, PMP, Project Initiation, Project Management, Risk Management, Schedule Management, Training, Writing and Documentaiton | | 3 Comments

Scope Change Control

Who hasn’t been on a project where scope creep is an issue? One of my pet peeves is when people try to add functionality (or even a bug fix) and don’t realize they need to inform the Project Manager and all prior documentation has to be changed. An engineer may be able to code a fix very quickly, but if he does that has ramifications on documentation, schedule management and quality control (to name a few). When someone tries to pull this, I always draw the infamous triangle of scope, time/cost and resources. If one changes, the others will as well.

One way to formally control this is to implement a formal scope verification process where you require a change to be communicated to the stakeholders’ for formal acceptance of the completed project scope and associated deliverables. Verifying the project scope includes reviewing deliverables to ensure that each is completed satisfactorily. If the project is terminated early, the project scope verification process should establish and document the level and extent of completion.

Scope verification differs from quality control in that scope verification is primarily concerned with acceptance of the deliverables, while quality control is primarily concerned with meeting the quality requirements specified for the deliverables.

Quality control is generally performed before scope verification, but these two processes can be performed in parallel; and when a change occurs (that is accepted) all project team members need to re-examine their project documents and schedule. Any corrective changes go to the project manager and new plans and schedules are produced. Then a process of verifying the scope occurs. The following lists potential outputs from Scope verification:

  1. Accepted Deliverables: The Scope Verification process documents those completed deliverables that have been accepted. Those completed deliverables that have not been accepted are documented, along with the reasons for non-acceptance. Scope verification includes supporting documentation received from the customer or sponsor and acknowledging stakeholder acceptance of the project’s deliverables.
  2. Requested Changes; Requested changes may be generated from the Scope Verification process, and are processed for review and disposition through the Integrated Change Control processes.
  3. Recommended Corrective Actions

For a successful project, the Project Manager is in charge of scope control. Scope control is concerned with influencing the factors that create project scope changes and controlling the impact of those changes. Scope control assures all requested changes and recommended corrective actions are processed through the project Integrated Change Control process. Project scope control is also used to manage the actual changes when they occur and is integrated with the other control processes. Uncontrolled changes are often referred to as project scope creep. Change is inevitable, thereby mandating some type of change control process. The biggest thing to remember is to communicate to all team members and stake holders during this process. It is wise to institute a formal change control system.

A project scope change control system, documented in the project scope management plan, defines the procedures by which the project scope and product scope can be changed. The system includes the documentation, tracking systems, and approval levels necessary for authorizing changes. The scope change control system is integrated with any overall project management information system to control project scope. When the project is managed under a contract, the change control system also complies with all relevant contractual provisions.

Project performance measurements are used to assess the magnitude of variation. Important aspects of project scope control include determining the cause of variance relative to the scope baseline and deciding whether corrective action is required. Earned value management is very helpful here. Approved change requests affecting the project scope can require modifications to the WBS and WBS dictionary, the project scope statement, and the project scope management plan. These approved change requests can cause updates to components of the project management plan.

A formal configuration management system provides procedures for the status of the deliverables, and assures that requested changes to the project scope and product scope are thoroughly considered and documented before being processed through the Integrated Change Control process.


January 19, 2009 Posted by | Project Management, Schedule Management, Scope Management | 3 Comments

A Successful Project Schedule


Project scheduling has always seemed to be somewhat of an art. Actually, there are a lot of logical steps that go in it. If I am the Project Manager, I have several tricks I always use to ensure that I do no bring my project in late or over budget. Here is my top list of scheduling tricks:


·         First, let’s assume we have a solid signed off Scope Statement Requirements document and the project is all set to go.

·         I make sure I know everyone participating in my projects and build relationships with them. If they are contributing to the schedule, this gives me an idea of what their ability level is and how well they can estimate their work. In any case, I keep a 20% management reserve to use as a cushion to give myself some wiggle room in the schedule when Murphy’s Law kicks in. For each individual, I know whether they under or over estimate and adjust accordingly. If I happen to have a person I don’t know well enough yet, I pad their estimates.

·         I schedule higher level architects or technical leads at 60% utilization because I know they will be pulled in to help the more junior engineers or to meet with upper management. For junior engineers, I schedule their time at 80% utilization to allow for sick days, vacations and meetings. I also make everyone use a Work Breakdown structure with the largest work package being 40 hours. I have the whole team review the WBS before I start the next steps in creating the schedule.

·         Note that the cost of a more senior engineer is higher and must be taken into consideration in the schedule. You may have a time when you have to make a tradeoff of cost vs. time.

·         Each element of the project scope, as defined in the WBS, must be supported by an activity, or activities, that will result in the completion of that part of the project scope. Activities must be described uniquely, have any assumptions listed and if there are known risks list them as well.

·         Once the activity list is defined, the order in which the activities will be performed must be determined and recorded. This is called activity sequencing. Things such as holidays, vacations, etc. must be taken into account at this step.

·         The resources required to complete each activity—including their availability and productivity—should be considered. I never estimate work for someone else. I always include the team in the estimating and sequencing. This gives a sense of buy-in to the schedule.

·         I use Microsoft Project Server as my scheduling tool to assemble the schedule model and provide the means of adjusting various parameters and components that are typical in a modeling process. It is a powerful tool that allows me to do what if analysis, critical path analysis and make changes on a daily basis. It allows me to schedule tasks as finish-to-start, finish-to-finish etc. depending on what is best for the project.

·         It also allows me to add lags and leads between activities.  I apply the resources using individual resource utilization percentages.

·         I add constraints where logic (precedence relationships with other activities) alone is not adequate to meet the project requirements.

·         I capture a specific schedule as a baseline or target schedule for the project. I may have a new baseline if certain factors dictate the need.

·         I use earned value analysis and trending analysis which are all easily done with Microsoft Project.


The key is to keep on top of the schedule every day and communicate to all the team members and stakeholders often (the communications are defined in the Communications Plan which is part of the overall Project Plan). If you catch an issue as soon as it happens, you have the tools to do various scenarios to get back on track. It is also important to publish the schedule or have it available to anyone can see it at any time. If you follow these guidelines you will have a successful project.

October 9, 2008 Posted by | Project Management, Schedule Management | , , , , | Leave a comment