Starting the Project out Right

First – make sure all stakeholders are at the first meeting. Also ask the Project Sponsor to tell everyone you are the Project Manager (transferring authority). Talk about the processes you will use and the communication everyone can excpect from you.

Once you have a definitive scope, write a requriements document to meet that scope and distriubute it and sign it off. After this point, any change in scope should go through  your defined scope mamangement process.

Do your schedule as a team and construct a Work Breakdown Structure. Break each task down until it is no more than 40 hours or less. Add them back up to get the schedule. If management doesn’t want the date you’ve come up with ask them which scope they want to drop. Remind them that each feature takes time from you (as PM), the coder, the tester, the documenter and suppport.

As you move from requirements to specifications and coding, adding scope is even more costly. It disrupts everyone. Try to put it in a subsequent release.

Above all, make sure you communicate schedule, risks and status very frequently; and hopefully have a team site on SharePoint that everyone can see.

Scope Creep

People have asked me how to stop scopr creep. The way I do it is to have a change review board that every scope change must go through to be reviewd. That usually stops the managers from adding scope since I ask theym to sign off on the change management board in the beginning.

The decond problem id when and engineer wants to add scope on his own. To stop that, I have team members put in their time daily and their remaining time to get a task done. That helps me to find potential scope creep.

It is also vital to explain the whole process to the team and stakeholders. No one really wants the projct to fail and when they realize the impact of adding a little code enhancement to the testing and documentation groups, they tend to stay away from it.

That being said, it is a #1 problem in Project Management. Just keep on top of the project at all times.

Linkedin Profile

Check out my Linkdin Profile at www.linkedin.com/in/dritter5!  I’d love to hear your comments on what services you would like provided.

 

Donna

Ways to remain calm during the PMP test

Make sure you have studied a lot. The test is a 4 hour multiple choice test that is randomly selected from PMI’s test base. Bring energy bars and water. They won’t let you take anything in, but will give you a locker to store your stuff. Take a break at least once an hour to stretch your legs, take a snack and break. This clears your head.

When you first get in the testing center, they give you paper and pencil. The first part of the test is a tutorial on how to take the test. Take this time to do a brain dump of all the formulas, knowlege areas and procces groups. The questions are very situational, so you can usually emliminate 2 answers quickly. If you are not sure, mark the question (it lets you do that to come back to it) and go on. Also, somethims questions further on into the test will help answer an earler question. Aim for 30 minutes for looking at the questions you didn’t feel sure about and to review your exam. THen as soo as you push the confirtm question, it will take a few minutes to grade (a long few minutes) but it will help a lot. I wasn’t sure I passed – but I made a 98%! Keep you PMP certifcation eu to date and you’ll never have to take the test again. When I took it, the rule was you had to get 60  PDUs in 3 years. You can get some from training or some from running projects, reading a new PM theory book and other things. Look on PMP.ORG to find out the requirements to keep your PMP certication. And get a good nights rest and calm yourself. No one knows what you make and I think they give you 2 or 3 times to pass.

 

Have a great day!

Donna

The Nature of Project Management

Why do many talented developers and IT professionals consider project management to be an obstacle, rather than an enabler? Why do clients often resist project oversight or try to minimize it? Does project management really allow projects to reach completion more quickly, or are speed and project discipline mutually exclusive?

We’ve explored the balance of speed and delivery and the nature of innovative projects in recent articles. Let’s tie these themes together and review techniques that help keep project management relevant to even the most unique and innovative programs.

Project bureaucrats

When I teach project management, I often draw a distinction between project managers and project bureaucrats. We’ve all had encounters with project managers who turned into bureaucrats. Project bureaucrats are more interested in ensuring that every step of the methodology is applied and every line of every form is filled in than in what’s actually happening on the ground. On the other hand, it’s common to meet project managers who apply minimal project methodology, yet, through their expert use of relationships and personal interactions, always seem to know exactly where the project stands.

In my experience, it’s the project bureaucrats who often leave a bitter taste with both the delivery team and the client. These project managers turned bureaucrats have forgotten one of the key rules of project management: don’t mistake the map for the journey. All the plans, charts, and milestones mean nothing if they aren’t consistent with the reality on the ground. And there’s the rub; especially in innovative projects, the plans and estimates are often based on a fallacy — there’s the idea that we can predict the progress of something that’s never been done before.

Project spec compliance = success? Not always

In his outstanding book Agile Project Management, Jim Highsmith offers two examples that emphasize the point. The movie Titanic, from a project management perspective, was a huge failure — over budget, over schedule, and plagued by unforeseen risks that threatened to derail the project at every turn. Motorola’s Iridium project, which spent billions of dollars launching satellites into orbit in order to make telephone service available worldwide, was a great project management success. Yet the market is the ultimate judge, and the project management compliance of Motorola’s venture didn’t save the project from failure, nor did the project management disaster (no pun intended) of Titanic’s production taint the film’s appeal to the public.

The lesson that project managers should learn from these examples is that compliance with project specifications does not constitute project success; in the ultimate analysis, only business results matter. Stated another way, the largest risk in any project is not that it will deviate from plan; it’s the risk that the final outcome won’t fulfill the real need. Predictive methodologies, such as the techniques championed by the Project Management Institute in its PM Body of Knowledge, can add tremendous value, especially for projects for which we have a historical basis to look to for precedent. For truly innovative projects, in which any prediction is little more than guesswork and for which we’ll be inventing never-before-seen products, we need to look for a new approach. Hence, the growing popularity of agile approaches.

Agile myths and truths

The central insight of agile methods is not that project overhead is a pain in the neck or that programmers like to be free; instead, it is the observable truth that, especially in innovative programs, customers can’t describe what they want until they see it, and prediction is inappropriate when there’s no way to visualize what the final result will be, let alone exactly how long it will take to build.

Unlike predictive methods, in which the planning, estimating, and risk assessment activities are all front-loaded and often are seen as a separate “planning” phase, agile approaches assume that the requirements will grow incrementally and iteratively as the project proceeds. This emphasis on “just enough” planning and requirements discovery is an acknowledgement of the fact that the key up-front activity in an agile approach is the creation of the first iteration of the product, so that the sponsor can see it and touch it, and discrepancies between the sponsor’s vision and the product created by the team can be modified to fulfill the current business need.

Agile project management is often misunderstood, as illustrated by the proliferation of articles about “agile myths.” Agile methods are not about “buying pizza and getting out of the way,” as these methods are often caricatured. Agile methods, from SCRUM to Highsmith’s APM Framework, are disciplined and structured approaches to product development, just as predictive methods are; these methods just address different types of problems.

Predictive and agile approaches have robust requirements discovery techniques, but agile methods acknowledge that requirements will evolve throughout the life of the project rather than up-front. Both approaches have stakeholder participation practices, but agile methods insist that stakeholders and sponsors are involved throughout the project in a collaborative, interactive manner. Predictive and agile both have mechanisms for integrating changing requirements into the plan, but the approaches use different techniques. Predictive techniques often apply restrictive change management procedures. Agile methods are specifically designed to encourage and implement beneficial change by providing an iterative, incremental approach to development focused on implementing, rather than controlling, positive change.

Innovative projects call for innovative methods, but that doesn’t imply, as many agile skeptics insist, that the benefits gained by applying structured project management techniques must be abandoned. Agile approaches are appropriate for creative, inventive projects because the methods integrate exploratory, collaborative techniques into the project process and acknowledge the mutating nature of exploratory IT projects into the PM methods we apply. Even PMI, in its newly published Body of Knowledge, recognizes the value of the iterative, incremental approaches advocated by agile proponents.

More to come

In subsequent columns, we’ll dig a bit deeper into the specifics of some of these techniques and explore ways that agile approaches can be combined with familiar, predictive techniques to apply exactly the right level of rigor to the project, no matter where it falls on the innovation spectrum.

Get weekly PM tips in your inbox
TechRepublic’s IT Project Management newsletter, delivered on Wednesday, offers tips to help keep project managers and their teams on track. Automatically sign up today!

Rick Freedman is the author of three books on IT consulting, including “The IT Consultant”. Rick is a Director in the Global Services Division of NEC America, and a trainer and course developer in the Agile Project Management practice of ESI, the international PM training company.

2009 Results of the Top 10 obstacles to Project Success

• Scope Creep
• Challenging Schedule
• Resource Challenge
• Minimal or non-existent testing
• Tardy Delivery of Project Tasks
• Delegated Responsibility Unrelated to Authority
• Finance Challenge
• Invisible Requirements
• Skill set Challenged Team
• The Disappearing Sponsor

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.

 

Building a Work Breakdown Structure

 

Building a Work Breakdown Structure

The WBS is a deliverable-oriented hierarchical decomposition of the work to be executed by the project team, to accomplish the project objectives and create the required deliverables. The WBS organizes and defines the total scope of the project. The WBS subdivides the project work into smaller, more manageable pieces of work, with each descending level of the WBS representing an increasingly detailed definition of the project work. The planned work contained within the lowest-level WBS components, which are called work packages, can be scheduled, cost estimated, monitored, and controlled.

 

On projects I’ve worked on, the project team would go into a conference room and use post it notes for each piece of work until we reached something that was a week or less. NOTE: It’s easiest to bring a roll of paper to put the post it notes on so you can roll the whole thing up to input it into soft format.

 

The WBS represents the work specified in the current approved project scope statement. Components comprising the WBS assist the stakeholders in viewing the deliverables of the project.

 

Work Breakdown Structure Templates

 

Although each project is unique, a WBS from a previous project can often be used as a template for a new project, since some projects will resemble another prior project to some extent. For example, most projects within a given organization will have the same or similar project life cycles and, therefore, have the same or similar deliverables required from each phase. Many application areas or performing organizations have standard WBS templates.

 

The Project Management Institute Practice Standard for Work Breakdown Structures provides guidance for the generation, development, and application of work breakdown structures. This publication contains industry-specific examples of WBS templates that can be tailored to specific projects in a particular application area. A portion of a WBS example, with some branches of the WBS decomposed down through the work package level.

 

Decomposition

 

Decomposition is the subdivision of project deliverables into smaller, more manageable components until the work and deliverables are defined to the work package level. The work package level is the lowest level in the WBS, and is the point at which the cost and schedule for the work can be reliably estimated. The level of detail for work packages will vary with the size and complexity of the project.

 

Decomposition may not be possible for a deliverable or subproject that will be accomplished far into the future. The project management team usually waits until the deliverable or subproject is clarified so the details of the WBS can be developed. This technique is sometimes referred to as rolling wave planning.

 

Different deliverables can have different levels of decomposition. To arrive at a manageable work effort (i.e., a work package), the work for some deliverables needs to be decomposed only to the next level, while others need more levels of decomposition. As the work is decomposed to lower levels of detail, the ability to plan, manage, and control the work is enhanced. However, excessive decomposition can lead to non-productive management effort, inefficient use of resources, and decreased efficiency in performing the work. The project team needs to seek a balance between too little and too much in the level of WBS planning detail.

5

Decomposition of the total project work generally involves the following activities:

 

·         Identifying the deliverables and related work

·         Structuring and organizing the WBS

·         Decomposing the upper WBS levels into lower level detailed components

·         Developing and assigning identification codes to the WBS components

·         Verifying that the degree of decomposition of the work is necessary and sufficient.

 

This analysis requires a degree of expert judgment to identify all the work including project management deliverables and those deliverables required by contract. Structuring and organizing the deliverables and associated project work into a WBS that can meet the control and management requirements of the project management team is an analytical technique that may be done with the use of a WBS template. The resulting structure can take a number of forms, such as:

 

·         Using the major deliverables and subprojects as the first level of decomposition.

·         Using subprojects where the subprojects may be developed by organizations outside the project team. For example, in some application areas, the project WBS can be defined and developed in multiple parts, such as a project summary WBS with multiple subprojects within the WBS that can be contracted out. The seller then develops the supporting contract work breakdown structure as part of the contracted work.

·         Using the phases of the project life cycle as the first level of decomposition, with the project deliverables inserted at the second level.

·         Using different approaches within each branch of the WBS, where test and evaluation is a phase, the air vehicle is a product, and training is a supporting service.

 

Decomposition of the upper level WBS components requires subdividing the work for each of the deliverables or subprojects into its fundamental components, where the WBS components represent verifiable products, services, or results. Each component should be clearly and completely defined and assigned to a specific performing organizational unit that accepts responsibility for the WBS component’s completion. The components are defined in terms of how the work of the project will actually be executed and controlled. For example, the status reporting component of project management could include weekly status reports, while a product to be manufactured might include several individual physical components plus the final assembly.

 

Verifying the correctness of the decomposition requires determining that the lower-level WBS components are those that are necessary and sufficient for completion of the corresponding higher-level deliverables.

 

Outputs of Creating a WBS:

 

·         Project Scope Statement (Updates): If approved change requests result from the Create WBS process, then the project scope statement is updated to include those approved changes.

·         Work Breakdown Structure: The key document generated by the Create WBS process is the actual WBS. Each WBS component, including work package and control accounts within a WBS, is generally assigned a unique identifier from a code of accounts. These identifiers provide a structure for hierarchical summation of costs, schedule, and resource information.

 

The WBS should not be confused with other kinds of breakdown structures used to present project information. Other structures used in some application areas or other Knowledge Areas include:

 

·         Organizational Breakdown Structure (OBS). Provides a hierarchically organized depiction of the project organization arranged so that the work packages can be related to the performing organizational units.

·         Bill of Materials (BOM). Presents a hierarchical tabulation of the physical assemblies, subassemblies, and components needed to fabricate a manufactured product.

·         Risk Breakdown Structure (RBS). A hierarchically organized depiction of the identified project risks arranged by risk category.

·         Resource Breakdown Structure (RBS). A hierarchically organized depiction of the resources by type to be used on the project.

 

The WBS Dictionary

 

The document generated by the Create WBS process that supports the WBS is called the WBS dictionary and is a companion document to the WBS. The detailed content of the components contained in a WBS, including work packages and control accounts, can be described in the WBS dictionary. For each WBS component, the WBS dictionary includes a code of account identifier, a statement of work, responsible organization, and a list of schedule milestones. Other information for a WBS component can include contract information, quality requirements, and technical references to facilitate performance of the work. Other information for a control account would be a charge number. Other information for a work package can include a list of associated schedule activities, resources required, and an estimate of cost. Each WBS component is cross-referenced, as appropriate, to other WBS components in the WBS dictionary.

 

The Scope Baseline

 

The approved detailed project scope statement and it’s associated

WBS and WBS dictionary are the scope baseline for the project. The next step is to estimate all of the work packages and create your baseline schedule.

 

Developing the Scope Statement and Project Plan

 

 

                        Developing a Project Scope Statement

 

The project scope statement is the definition of the project—what needs to be accomplished. The Develop Preliminary Project Scope Statement process addresses and documents the characteristics and boundaries of the project and its associated products and services, as well as the methods of acceptance and scope control. A project scope statement includes:

 

·         Project and product objectives

·         Product or service requirements and characteristics

·         Product acceptance criteria

·         Project boundaries

·         Project requirements and deliverables

·         Project constraints

·         Project assumptions

·         Initial project organization

·         Initial defined risks

·         Schedule milestones

·         Initial WBS

·         Order of magnitude cost estimate

·         Project configuration management requirements

·         Approval requirements

 

The preliminary project scope statement is developed from information provided by the initiator or sponsor. The project management team in the Scope Definition process further refines the preliminary project scope statement into the project scope statement. The project scope statement content will vary depending upon the application area and complexity of the project and can include some or all of the components identified above. During subsequent phases of multi-phase projects, the Develop Preliminary Project Scope Statement process validates and refines, if required, the project scope defined for that phase.

 

Project Scope Development Tools and Techniques

1 – Project Management Methodology

The project management methodology defines a process that aids a project  management team in developing and controlling changes to the preliminary project scope statement.

 

2 – Project Management Information System

The project management information system, an automated system, is used by the project management team to support generation of a preliminary project scope statement, facilitate feedback as the document is refined, control changes to the project scope statement, and release the approved document.

 

3 – Expert Judgment

Expert judgment is applied to any technical and management details to be included in the preliminary project scope statement.

         

Develop Project Plan

 

The Develop Project Management Plan process includes the actions necessary to define, integrate, and coordinate all subsidiary plans into a project management plan. The project management plan content will vary depending upon the application area and complexity of the project. This process results in a project management plan that is updated and revised through the Integrated Change Control process. The project management plan defines how the project is executed, monitored and controlled, and closed. The project management plan documents the collection of outputs of the planning processes of the Planning Process Group and includes:

 

·         The project management processes selected by the project management team

·         The level of implementation of each selected process

·         The descriptions of the tools and techniques to be used for accomplishing those processes

·         How the selected processes will be used to manage the specific project, including the dependencies and interactions among those processes, and the essential inputs and outputs

·         How work will be executed to accomplish the project objectives

·         How changes will be monitored and controlled

·         How configuration management will be performed

·         How integrity of the performance measurement baselines will be maintained and used

·         The need and techniques for communication among stakeholders

·         The selected project life cycle and, for multi-phase projects, the associated project phases

·         Key management reviews for content, extent, and timing to facilitate addressing open issues and pending decisions.

 

The project management plan can be either summary level or detailed, and can be composed of one or more subsidiary plans and other components. Each of the subsidiary plans and components is detailed to the extent required by the specific project. These subsidiary plans include, but are not limited to:

 

·         Project scope management plan

·         Schedule management plan

·         Cost management plan

·         Quality management plan

·         Process improvement plan

·         Staffing management plan

·         Communication management plan

·         Risk management plan

·         Procurement management plan

 

These other components include, but are not limited to:

 

·         Milestone list

·         Resource calendar

·         Schedule baseline

·         Cost baseline

·         Quality baseline

·         Risk register

 

          Project Plan Tools and Techniques

Project Management Methodology

The project management methodology defines a process, which aids a project management team in developing and controlling changes to the project management plan.

 

Project Management Information System

The project management information system, an automated system, is used by the project management team to support generation of the project management plan, facilitate feedback as the document is developed, control changes to the project management plan, and release the approved document.

 

·         Configuration Management System The configuration management system is a subsystem of the overall project management information system. The system includes the process for submitting proposed changes, tracking systems for reviewing and approving proposed changes, defining approval levels for authorizing changes, and providing a method to validate approved changes. In most application areas, the configuration management system includes the change control system. The configuration management system is also a collection of formal documented procedures used to apply technical and administrative direction and surveillance to:

o   Identify and document the functional and physical characteristics of a product or component

o   Control any changes to such characteristics

o   Record and report each change and its implementation status

o   Support the audit of the products or components to verify conformance to requirements.

 

·         Change Control System The change control system is a collection of formal documented procedures that define how project deliverables and documentation are controlled, changed, and approved. The change control system is a subsystem of the configuration management system. For example, for information technology systems, a change control system can include the specifications (scripts, source code, data definition language, etc.) for each software component.

 

·         Expert Judgment Expert judgment is applied to develop technical and management details to be included in the project management plan.

 

 

 

---

[i] A Guide to the Project Management Body of Knowledge (PMBOK® Guide) Third Edition

2004 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA

Project Process Groups

There are five Process Groups defined by PMI. They have clear dependencies and are performed in the same sequence on each project. They are independent of application areas or industry focus. Individual Process Groups and individual constituent processes are often iterated prior to completing the project. Constituent processes also can have interactions both within a Process Group and among Process Groups.

 

Note: During project phases, if a change occurs during the project execution or control, the documents and tools used in the Process groups may have to be revisited. For example, if a change is made to the scope during the project execution phase, the scope document and all of the project plans must be revisited to include the new scope.

 

An individual process may define and constrain how inputs are used to produce outputs for that Process Group. They are defined in a way that projects of all kinds can be managed with this standard, so some inputs or outputs may not be relevant to every project.

 

A Process Group includes the constituent project management processes that are linked by the respective inputs and outputs, that is, the result or outcome of one process becomes the input to another. The Monitoring and Controlling Process Group, for example, not only monitors and controls the work being done during a Process Group, but also monitors and controls the entire project effort. The Monitoring and Controlling Process Group must also provide feedback to implement corrective or preventive actions to bring the project into compliance with the project management plan or to appropriately modify the project management plan. Many additional interactions among the Process Groups are likely.

 

Where large or complex projects may be separated into distinct phases or sub-projects such as feasibility study, concept development, design, prototype, build, test, etc. all of the Process Group processes would normally be repeated for each phase or subproject.

The five Process Groups are:

 

·         Initiating Process Group. Defines and authorizes the project or a project.

·         Planning Process Group. Defines and refines objectives, and plans the course of action required to attain the objectives and scope that the project was undertaken to address.

·         Executing Process Group. Integrates people and other resources to carry out the project management plan for the project.

·         Monitoring and Controlling Process Group. Regularly measures and monitors progress to identify variances from the project management plan so that corrective action can be taken when necessary to meet project objectives.

·         Closing Process Group. Formalizes acceptance of the product, service or result and brings the project or a project phase to an orderly end.