Project management is always a matter of scale.  It is not a one size fits all proposition and there are times when we as project managers should remember to just do the simple things.  Sometimes the K.I.S.S. (keep it simple stupid) principle is really the best.  Imagine you have just been asked to organize the team rollout victory party for next week.  That’s the project.  You have 2 administrative assistants to help you.  That’s your team.  Are you going to develop a WBS dictionary, document a communication plan, and perform a quantitative assessment of risks?  I doubt it.  By the same token will you abandon any semblance of planning and completely wing it?  I hope not!  Not if you are a project management professional.  Any endeavor that is temporary and produces a unique product, service or result deserves a plan – one of appropriate size and scale.

Scope:  So, in our example you sit down with your 2 administrative assistants in your office and pull up a spreadsheet.  The 3 of you brainstorm what tasks need to be done in the next week to pull off the team party.  You discuss where the party will be held, what food will be brought in, how invitations will be handled, entertainment, etc.  You capture all these tasks in a column of the spreadsheet.  You have just defined the scope of your project as a list of tasks.

Resources: Next, you decide who is going to do each task on your list.  There are only the 3 of you on your team so one of the 3 of you has to be assigned to each task.  In a 2^nd column of the spreadsheet you assign a name to each task.  You have just performed resource allocation.

Schedule: Next, the team needs to determine when each task needs to be done.  This is an example of a time-boxed, fixed date project.  The party will be communicated for a specific date, so all preparation activities must take place prior to that date.  Working backwards from the party date, in a third column, the team fills in target date/times of when tasks must be completed by.  You have just performed activity dependency and scheduling for your project.

Budget: You think about how much each task will likely cost and note that in a 4^th column.  The sum of these cost estimates forms your budget.

Risk:  You ask your team “Is there anything that worries you?”   One of the admin assistants replies: “What if we can’t reserve a restaurant large enough on such short notice?”  So, you decide to add a task to the list to reserve a large conference room at your company and investigate catering at the company as a backup precaution.  You have just performed some risk management planning. Maybe it is not extensive or as rigorous as it could be, but it is better than doing nothing, and probably appropriate for this size effort.

Communication and project execution:  You decide to have a daily 15 minute meeting over the next week as you each carry out your assigned tasks.  I like the agile iterative process format for daily meetings as far as providing a simple way to get project updates.  In each meeting, every team member answers 3 questions:

1. What have you done since the last time we met?
2. What do you plan to do between now and the next time we meet?
3. What impediments are preventing you from making progress?

In answering those 3 questions, you are providing progress measurements that can be compared to the plan.  You are providing forecasts that indicate if adjustments are warranted.  You are highlighting issues and risks that may lead to offline discussions to develop ad hoc workaround plans.

With a simple spreadsheet and some basic, obvious conversation you can manage a small non-complex project.  The tools used are not important, as long as the necessary steps of the project management process are covered.

Processes:   The primary scrum processes allow for grooming of the product backlog or clarifying the complexity by specifying effort factor (story points), grouping work from the product backlog into work iterations, defining and estimating technical work tasks for the work iterations, and packaging completed outputs of the work iterations into a working release product.  Below is a breakdown of the different scrum processes along with their descriptions and analogous waterfall counterpart.

Meetings:    Since frequent feedback is the hallmark of agile, the scrum meeting are the settings that facilitate some of the above processes, as well as allow for frequent status during the work intervals or sprints, and provide the vehicle for the customer acceptance and process improvement.  Below is a table that describes the major scrum meetings, descriptions and their waterfall counterparts.

 Artifacts:  Artifacts are sparse compared to a typical waterfall methodology. All work “to do” is tracked on the product backlog.  Work “left to go”  is tracked on one of 2 types of burn down charts and are meant to show progress to the organization.  Business requirements will seem sketchy in agile as compared to waterfall since preference is given to conversations amongst members of the team, and verification through acceptance criteria and demonstrations.  Below is a description of scrum artifacts.

 In scrum, relative estimation keeps the estimation process intuitive and non specific.  It’s done in group session with the entire team where everyone “votes” on their number all at once to keep voting independent.  The relative story points assist the product manager in backlog prioritization.  Sprint planning makes up the rest of the planning for a 30 day period.  This is where the detailed task decomposition and hourly estimation occurs.

Once a sprint is planned, work is executed and monitored in the daily standup meetings.  Issues are tracked in the Sprint impediment log.  Progress is displayed to the organization in artifacts such as the sprint and product burn down charts.

At the end of the sprint, the work is verified and accepted or rejected in the sprint demonstration meeting.  Then the sprint processes are reviewed and suggestions for improvement are made in the sprint retrospective, before reprioritizing the product backlog if necessary and beginning a new sprint.

I first became interested in agile when I was leading technology teams and consistently struggled with the standard waterfall challenge of getting accurate, complete, well understand and well documented business requirements for long software development application projects.  Once we felt like we finally got things “nailed down” and began design and development work, requirements would change before we could deliver the first release.  The agile methodology is a natural solution for this.  I began my own course of self study, networking and training, and eventually acquired a scrum master certification.

To understand the principles of any of the flavors of agile methodology (and there are several), you need to first understand the agile manifesto, developed by the original set of agile founders:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

Scrum happens to be one of the most popular types of agile and derives its name from a daily standup meeting called the scrum meeting, involving the team and the facilitator who is called the scrum master.  Below is a discussion which breaks down some of the important roles used in scrum and compares them to their analogous counterpart in a waterfall methodology. 

Roles – there are only 3 officially recognized roles on an agile scrum team:

• Product Owner – The product owner is a member of the scrum team and is responsible for what the team builds and for optimizing the value of it.  He/she owns decisions and risks regarding what business stakeholders want.  He/she defines the features to be produced and decides on release date and content, and determines feature priorities.  He/she can change features and priority between sprints.  He/she negotiates acceptance criteria for work results with rest of team
• Scrum Master – facilitates process and keeps things moving.  He/she manages the internal dynamics of the team including the relationship of the product owner with the rest of the team.  He/she enforces the scrum framework.  He/she ensures full team involvement in all meetings and keeps everything visible, including “radiating” information to the larger organization.  He/she shields the team from external interference.  He/she advocates improved practices.  Very important:  He/she facilitates, but does not manage.  The scrum master has no official authority over the team.  He/she cannot assign work to the team.
• Team – This is a small (7 +-2 member) cross functional group who are responsible for the work they agree to take on during the work period called a sprint.  They are a self organizing unit – meaning they assign sprint work tasks to themselves.  They negotiate the work of the sprint with the product owner.  Along with the product owner, they demo the work results to the stakeholders.

The product owner is analogous to a business analyst, product manager or sponsor in a waterfall methodology, and the team is similar to any team anywhere, with the exception of the self organizing part.  That’s a little loose-y goose-y for a lot of management teams to get used to.  Frankly, what I’ve seen in a lot of companies I’ve networked with is a gradual approach to this, because as much as this sounds like a great goal, in companies that have been highly command and control, teams have to get as used to it as the managers themselves do.  The scrum master could be similar to a technical team lead or a technical project manager in some organizations.  What is strikingly missing in this model is the overall project manager him/herself.  The traditional, all controlling, project manager doesn’t really have a direct correlation.  To find a home in an agile practicing organization the PMI style project manager has to make some decisions.  For individuals with a more product oriented, business slant, the product owner might be a great role to assume.  For the more technically minded, the scrum master role might be a better fit.

One of the most intriguing differences between agile and waterfall and what in my mind makes agile so compelling is in the area of scope control.  In the waterfall methodology we go to great lengths to define the scope of the project in as much detail as we can all up front, and then protect that scope.  We define a rigid scope change process which acts as a deterrent to anyone who wants to introduce changes to the work that we already have a complex tangle of design plans around, because of the cost and pain of implementation when you work on everything all at once.  With agile the notion of scope control is virtually non-existent, except within the context of the short periods of work, called sprints.  This is by design.  This is to allow and even encourage the product owner to be flexible and change their mind in between sprints as the business sees the results of work and reacts to it; and as events in the business change. 

In a nutshell, product features and all other work are maintained in a document called the product backlog, in single threaded priority by the product owner.  The team determines “chunks” of that work off the top that they can perform in time boxed periods of work called sprints (usually 30 days).  Once a sprint starts, the scrum master insures that the scope of the sprint does not change.  At the end of the sprint the team and the product owner jointly demo the work that has been completed to the business stakeholders.  The product backlog is reprioritized if necessary by the product owner and another sprint is started.  Sprints are repeated until enough work is completed to comprise a release.  Sounds simple huh?  Well there’s a little more to it than that.

In my next article I will discuss the small set of artifacts, meetings and processes involved and discuss what they compare to in a waterfall context.

It is generally considered that a well defined requirement possesses the following attributes:

• Necessary – The system cannot meet prioritized needs or goals without the requirement
• Feasible – The requirement is doable, within available cost and schedule
• Correct – The facts related to the requirement are accurate and it is technically and legally possible
• Concise – The requirement is stated simply
• Unambiguous – The requirement can only be interpreted one way
• Complete – All applicable conditions are stated, and the requirement expresses a whole idea or statement.
• Consistent – The requirement is not in conflict with any other requirements
• Traceable – The requirement can be traced to its source, and it can be tracked throughout the system, (e.g., to the design, code, test, and documentation)
• Allocated – The requirement is assigned to a component of the designed system
• Design independent – The requirement does not impose a specific implementation solution
• Non-redundant – The requirement is not a duplicate requirement
• Stated using a standard construct – The requirement is stated as an imperative using the word shall
• Associated with a unique identifier – Each requirement has a unique identifying number
• Devoid of escape clauses – Requirements do not use if, when, but, except, unless, and although, and do not include speculative or general terms such as usually, generally, often, normally, and typically.

Additionally, a business requirement differs from a business rule.  According to Gladys S.W. Lam, Principal at BRSolutions.com, who writes in her article, “Business Rules vs. Business Requirements,” Business Rules Journal, Vol. 7, No. 5 (May 2006), URL:  http://www.BRCommunity.com/a2006/b290.html  ,

• Business rules are lists of statements that tell you whether you may or may not do something or that give you the criteria and conditions for making a decision
• Business requirements are what you need to do to enable the implementation of and compliance with business rules.

• Business rules are what they are.  They shouldn’t change to fit the business requirements.
• A change in a rule can mean different or additional requirements.

An example of a business rule might be: 

A Customer must have an Email Address

The associated business requirement that enables implementation and compliance with that business rule is:

Customer must have capability to enter email address for a customer. 

The solution chosen to implement that requirement might be to provide a GUI. 

Obviously, requirements such as the one stated above are still fairly high level and must still be broken down further before they could be actionable by an implementation team.  There are still more detailed specifications related to the capability to enter an email address such as which fields to enter, error handling, and many other aspects that a development team should define.

Business requirements are best defined in layers with a set of un-actionable requirements such as: Customer must have capability to enter email address, at one layer, and the lower level specifications related to that requirement captured at a layer beneath it and tied back to the requirement above it.

According to Dictionary.com, a template is “anything that determines or serves as a pattern; a model”.  The idea of a Requirements Template is to provide your organization with a thorough and far-reaching list of questions or areas of inquiry to either answer or rule out at the beginning of every project.  If you include input from enough people and groups, whether they typically identified as project stakeholders or not, you can eliminate many of the scope problems that your organization’s projects might have encountered in the past. 

If you ever do projects for external customers, start your template-building exercise with Marketing and Business Development.  Ask them about what types of features customer and prospects initially express interest in and what marketing and advertising messages they respond to.  This can give you some good high-level areas of inquiry for your Template by helping you understand what prompts your external customers to engage with your organization. 

Next, visit with the Sales group and ask them to think about every problem customers have identified as wanting to solve when they accept a sales proposal.  Ask them also to think about customer satisfaction issues after a sale is completed:  what characterized projects that had satisfied customers, and what characterized projects that didn’t.  Ask them to describe situations where the customer was temporarily unhappy and why.  Ask to see any type of documentation they use to begin identifying what a customer wants. Then start building your list of questions. 

If you are dealing only with internal customers, start by reviewing the documents that accompany any request for a new project.  You want to include all of this information, but your template will go into much greater detail.  Interview someone from your organization’s Steering Committee and ask them what is missing from the current initiation documents they use.  Ask for examples of specific projects that got kicked back from the Steering Committee due to insufficient information, and get them to identify the types of additional information needed for them to make a ruling on a new project.  Continue building your Template by adding this to your list of questions.

Next, visit with all the teams that are responsible for executing the project plan.  Talk to developers, DBAs, cost estimators, trainers, folks who do the documentation; basically, everyone who actually performs work on a project in your organization.  Ask them for a list of everything they end up needing to know in the middle of the project that no one ever asked at the beginning.  Ask them what kind of work they are doing in the stabilization period, and if that work is a result of missed requirements.  Ask them for the most common examples, as well as the outliers.  Your goal is to create a comprehensive list of everything that should be considered at the beginning of a project.

Then move on to your support teams – whoever is responsible for the product of the project once it is operational.  Ask them to identify the things they wish someone on the project team was asking about.  Again, ask for the odd and unusual situations as well as the most common examples.

Finally, spend a little time with other groups that may not be at all involved in the project, but can potentially be affected problems with a project, like Legal, Accounting, Corporate Compliance and Public Relations.  Ask if they have ever been affected by missed project requirements, or have an area of potential concern around project requirements.  Document their concerns as areas of inquiry to consider during the requirements phase.

If you have all these conversations and hear all these war stories, you will be able to create a useful tool for the people in your organization who have the responsibility of collecting requirements.  Continue to updated and modify your Requirements Template as new information becomes available. 

In addition to getting your project off to a good start and nipping some scope creep issues in the bud, you may find that this tool helps you have better conversations with customers, both internal and external, by helping them uncover needs they didn’t know they had or gaps in their process they hadn’t discovered yet.

Good luck!

Assuming the decision is to scale back on requirements, the real fight usually begins with stakeholders as to which ones.  If they have evolved as a veritable sea of equal and indistinguishable specifications, it comes down to an arm wrestle or the decision is based on criteria which may have little to do with business value. 

A better approach is to start the business requirement development process at a high level with an identification of goals and objectives.  In other words, get crisp and clear about what problem you’re trying to solve, or what pain you’re trying to alleviate; and what intermediate steps will be targeted to get you there.  Then align all requirements to one or more of the steps that are tied to the goals.  The idea is that while it is difficult to prioritize one requirement over another in a large universe – especially when many advocates are lobbying for their favorites, it is usually easy to prioritize or categorize goals.  Executive sponsors do this.  The requirements that stem from their parent goals inherit the relative priorities.

First off, a review of goals vs. objectives is in order, as many people confuse them. 

• Goals are broad, lofty ideas.  They are intangible, abstract, and cannot be validated.  Goals are usually derived as responses to business need or opportunity.  Some examples of goals might be:  Gain a greater appreciation for Latin music, or Know about the human body. 
• Objectives are succinct statements including key parameters in areas of time, scope, resources/cost and they are tied to a goal.  Objectives are SMART – specific, measurable, attainable, relevant, and time bound.  The goal is where we want to be, the objectives are the steps needed to get there.  Some examples of objectives related to the above goal examples might be: Attend 3 live concerts featuring Latin American music by the end of the semester.   Name all the bones in the human body as stated in the medical text book by the time I am scheduled to take my test.

With that as a backdrop, let’s consider a football analogy.  (I apologize in advance to my international colleagues, but this will be American football.)  Let’s say you are the coach of a college football team and you have a big game coming up against a rival team.  What is your goal?  Quite simply, to win the game!  No more specific than that.  The number of points doesn’t matter.  Now let’s say that based on your analysis of the other team’s skill and your team’s strength, you believe that in order to win the game your team needs to put up at least 24 points.  You don’t want to have to do all of that scoring at the end of the game so you tell your players that you want them to target at least the following scoring opportunities:

                By end of 1^st Qtr – Field Goal

                By end of 2^nd Qtr – Touchdown + Pt After

                By end of 3^rd Qtr – Touchdown + Pt After

                By end of 4^th Qtr – Touchdown + Pt After

 What you’ve just communicated are objectives tied to your goal.  They’re specific, measurable, attainable, relevant, and time bound.  You believe if the team achieves the above scoring objectives they will attain the related goal of winning the game.  So what are the requirements related to these objectives?  Simply stated, for the first one it is to snap the ball, hold it and kick it from the line of scrimmage so that it goes between the goal posts.  For the others, it is to move the ball down the field from the initial point of possession to and across the goal line.  Notice I didn’t say anything about running certain types of running plays or passing plays, various routes, etc.  Those are implementation details left to the designers of the plays.

 Now as a college coach you are also interested in the professional futures of your student athletes.  You may have some star players who are nearing a record of some type.  You have additional goals of helping your players advance in their future NFL careers.  That may drive objectives for certain players of helping them reach certain records within the season.  The related requirements to that objective would be putting the players in, so they can rack up the yards towards their record.  However, clearly this goal is secondary to the goal on this day of winning this game! 

 So you can see how tying requirements to objectives which are tied to goals helps categorize and prioritize which can assist when there are tough decisions to be made about scope of work on a project.

Work breakdown structures are simply a way of organizing the work activities necessary to implement the project into a numbered outline form.  One of the best advantages that then comes from that is a way to provide traceability from then on throughout your project between requirements, project plans, test cases, issue logs, etc. This helps ensure nothing is lost in the cracks.  Notice I said traceability between requirements and implementation work in the WBS.  That’s an important distinction to make.  I’m a firm advocate that requirements should also be uniquely identified perhaps in a matrix or outline form, but that’s not the WBS, requirements are, well requirements, or the “what” or needs.  The WBS is an outline of the activities that the project team creates to implement those requirements.  It is the “how” or work tasks to deliver on the needs.

There are not many hard fast rules about how to construct a WBS.  Remember basic outline rules from English class in school, and use common sense and good judgment.  Generally speaking at the highest level, of the WBS outline is the object or product that your project was commissioned to produce. At the next level down could be major subcomponents, or phases of the project.  That’s where the judgment comes in.  Think of what constitutes the major chunks of work.  One of the “rules” is that one of the branches should include all the project management work, and another rule is that each branch should be complete; meaning all the subcomponents on a branch should add up to 100% of the work of the branch.  Makes sense, right?    If there is testing or integration work, that should probably be represented as well. 

So now let’s talk about traceability.  To me, this is the real advantage of using a WBS.  It makes you account for every requirement, and conversely it helps prevent scope creep by proving that every bit of work you are doing was justified by a requirement.  Let me say that again – it helps you prevent scope creep!    First, let’s discuss traceability of requirements to business objectives.  As the project scope is progressively elaborated through project charter or project definition phases through the creation of scope statements or statement of work, high level business needs, project objectives and goals will be documented.  Then, as the high level requirements are identified, it is a good idea to tag them with a unique identifier, and associate them with the project objective that they stem from.  That ensures that requirements are aligned to the objectives and business needs.  Then as the work is defined in the WBS to implement the requirements, each of those WBS elements can be tied to one or more requirement IDs.   A single requirement may be totally or partially implemented by multiple WBS elements, and/or a single WBS element may contribute to the implementation of multiple requirements.  Having a traceability matrix reveals where the connections are, which then directly assists in creating functionality test cases.  It helps ensure that no requirement has been overlooked, and that no work is the result of scope creep if it can be tied back to requirements that are themselves tied to the original business needs that justified the project business case.   Given all this incentive I’ve now hopefully instilled for creating work breakdown structures, let’s see if we can eliminate some of the reservations over difficultly.  Consider this example of a business case for a project to implement a software applicant tracking system.

Business Need:  Fill Open Positions with quality candidates in a timelier manner.

    Objective 1:  Reduce the amount of time recruiters spend reading and filtering resumes.

    Objective 2:  Reduce the amount of time recruiters spend corresponding back and forth with candidates collecting information.

    Objective 3:  Improve our ability to file and locate candidate records.

Based on the above high level need and resulting business objectives, the following high level requirements (not a complete list) may be captured and associated with the objectives.  There is obviously still a great deal of detailed requirement elaboration to be done on each one, but the high level requirements are captured below.

The high level WBS for the implementation work might look like something as follows.  (Normally, you would probably define activities to enough levels below the first level as necessary to be able to plan and manage the work):

Applicant Tracking System Implementation

1.0   Requisition Posting Module

1.1   Setup Requisition Filter options

2.0   Resume Capture

2.1   Configure Resume Storage facility

2.2   Setup Filtering Options

3.0   Build Questionnaire

4.0   Setup employment application

5.0   Testing

5.1   Test requisition

5.2   Test resume Capture

5.3   Test Questionnaire

5.4   Test employment application

6.0   Project Management

Once you have both the requirements table above and the WBS, you can then create a traceability matrix that proves you have addressed all the requirements and that you have not taken on any unnecessary work.  You should make each of the lowest items in each branch of the WBS appear in the matrix as well as each Requirement:

So if you’re one of those who have been avoiding this important and beneficial step in project planning, go ahead and give it a try on your next project.  I bet it won’t be nearly as scary as you think, and it just may keep you from forgetting something important.

For the next few weeks, I will be blogging about how we, as project managers, can help our project teams think more creatively.  In my last blog, I looked at the systems and causes of teams that are in a creativity crisis.  Today, I offer the first technique for helping your team break out of a creativity rut.  I will follow with many more techniques over the next several weeks. 

The Six Thinking Hats was created by Dr. Edward de Bono, M.D., a pioneer in “deliberate thinking models” who believes that conventional thinking needs random interruptions so creative thinking can take place.  Dr. de Bono has several different approaches to thinking and has published many books over the last 40 years.  One of his most popular concepts is the Six Thinking Hats, which is designed to help groups think together more effectively.  Sounds like a great idea, right?  I have certainly participated in a number of “brainstorming” meetings over the years where precious little thinking was in evidence! 

The premise behind the Six Thinking Hats is that the human brain thinks in six discrete ways which can be harnessed individually to produce different ideas.  When considering the same topic, each of the six thinking states will generate different ideas on the same topic.  Each state is identified with a color, and many practitioners of this method will actually provide “thinking hats” in every color to every meeting participant.  By putting on a hat of a certain color, you are aware of the type of thinking you are engaged in. 

The six states and the associated colors are:

• Questions (White) – What are the facts?
• Emotions (Red) – What are the feelings?  
• Judgment (Black) – What are the flaws?  What are the difficulties and the dangers?
• Good points (Yellow) – What are the benefits? What is positive about this idea?
• Creativity (Green) – Where can we go with this thought?  What are the possibilities?  What are the alternatives? 
• Thinking (Blue) – Are we managing the thinking process?  

Obviously, the Black hat, judgment, is one that all project teams are familiar with.  With a cohesive team that works well together, you probably wear the Yellow hat and acknowledge benefits to the ideas generated by your group thinking exercises.  You may even put on the Green hat and get creative with teams that trust each other and enjoy collaborating.  A good project manager probably wears the Blue hat, for managing processes, quite often when running meetings. 

But what about the White hat, the facts? How often, when identifying requirements, solving a project problem or assessing a risk, do we rush through the facts?  Or treat assumptions as facts?  Or treat facts as assumptions?  Wearing the white hat, either literally or figuratively, might help our teams avoid some project problems. 

And finally, the Red hat, which represents emotions.  Few project teams spend any time or effort on emotions, unless the ignored emotions erupt, causing a situation that has to be confronted.  Not only is it useful to address your project team’s emotions, you have to put the Red hat on and discuss emotions when you are planning any sort of activity or event that will change people’s jobs.  Any student of Organization Change Management will tell you that you ignore organizational emotions at your peril.    

De Bono’s Six Thinking Hats can help you think comprehensively about any topic confronting your team.  This has been a very brief overview, but there is plenty of information available online to learn more about this technique.  For more information, start at Dr. De Bono’s website, http://www.debonogroup.com/six_thinking_hats.php.

Stay tuned next time, for some additional techniques to improve team creativity.

Most people who have worked on a project in any capacity are familiar with the notion that projects are controlled constantly by what’s known as the triple constraint – time, cost, and scope.  You can control any 2 of those factors and the third one will be defined for you.  Never do projects begin with a fixed amount of time or budget and an organization saying  “Gee, I wonder what work we could go do with all this time and money?”  Projects begin because there is a specific need to address, problem to solve, or opportunity to realize – i.e. scope.  It must be the first thing defined and boundarized in a well formed scope statement.  After that you determine the amount of time and cost to adequately deliver the scope of work of the project.  While I will concede that neglecting schedule, budget, quality, communications, human resource issues or risk management can certainly hurt a project badly, neglecting scope management will kill a project.   This is because it is the very essence of what defines success for the project.  It is the “what you are doing” on the project.  You can work very fast and inexpensively, but if you have worked on the wrong things, you will not be declared successful.

From a public relations perspective, scope can be one of the areas that generates the greatest potential for confusion so project managers should begin communicating what is in and out of scope early and often to wide audiences of stakeholders – within and beyond the project team.  One of the worst morale killers on a project is when a high level stakeholder says late in the game “but I thought I was getting ‘X’ “.  The project charter and high level scope statement documents serve as good tools to aid in these types of presentations.   Once the detailed baseline scope statement is developed, it should be formally approved by the project sponsor, communicated widely, and constantly controlled.   To control the scope, we advocate adopting a form for use in capturing scope change requests from the outset and setting up a committee of sponsoring stakeholders (not including the project manager) responsible for approving  changes.  Change requestors should document the change and presumed benefits, and the implementation team should have a chance to document the impact to the current project schedule and budget.  This package is then presented to the change committee for decision.  The project manager must communicate the final decision to all stakeholders and factor the impact back into the project plan.  This allows sponsors to remain in control of the resources, and keeps the project manager from being the “bad guy” if the decision is No.  It also provides a mechanism for protecting the team against taking on extra work without the benefit of the time or extra resources to accomplish it.

So it behooves project managers to seek out opportunities to communicate scope as often as possible.  Let’s review some of the typical venues and aids for scope communications:

Keeping all interested parties aware from the outset of the approved scope, and any subsequent changes, so that there are no surprises downstream is in the best interests of the project team.