How to deliver structured, consistent planning estimates

February 3rd, 2010 Cindy Vandersleen

In my last article, “Is it bigger than a breadbox”, I talked about the three points in a project when estimates are usually delivered.  The topic of that article was the rough order of magnitude (or ROM) estimates generally given during the project selection process or at project initiation.  Those estimates can have +- 50% margin of error in them due to lack of information.  Once the project is approved, the team begins working on scope definition artifacts, developing first a high level, then a detailed scope statement, and a work breakdown structure to establish a scope baseline.  What I want to discuss in this article is a method to derive a planning estimate at a point where the high level scope statement is created, but before the detailed scope definition or WBS artifacts are finalized.

Planning estimates are generally considered to have an accuracy of 10 to 25% from actual.  This is because more information is known at this point than at the project selection or request point, but not as much as when all requirements have been finally required and refined.  Now obviously this is dependent on my subjective definitions of “high level scope statement” vs. “detailed scope statement”.  Scope should be outlined enough to describe feature sets or groups or deliverables and their basic functionality.  Once this is available, a working group of key representatives from each major component of the technical implementation team should be assembled to formulate the planning estimate. For example, web developers, database administrators, server developers, report developers, and any other specialty discipline required for the solution.  The scope elements detailed in the high level statement should be listed and grouped together by feature set.  For each element or combination of scope elements, the technical team identifies the technical work components required to deliver the solution in abstract.  By abstract, I mean high level, non – actionable work units.  For example, let’s say the high level scope statement contains language outlining the need for a web application and screen interfaces that facilitate employee registration for training classes.  The high level or abstract work units might be a set of database definition tables to define employee information, as well as a set of tables to define the training class information, as well as user interfaces to allow maintenance of schedules by administrators, and attendance requests by employees.  When the actual database elements get designed, they will no doubt manifest into a family of related tables with proper referential integrity for the employee information, and another similar family of tables for the training class information.  But at this point in the process, the team simply identifies a unit of work of database definition for each of the major hubs of data tables involved.  Similarly, there is a unit of work identified for a UI for standard screen maintenance of class information, and a UI for employee registration.  The fine details of what exactly are on each screen are not considered or detailed at this point.  The team uses a combination of analogous estimating and expert judgment to consider the work that resulted on past projects.

Now what creates consistency is to develop a scale, where for every type of work, and for a range of complexity levels, you record pre-set metrics (which are validated and calibrated over time).  These values can then be plugged in to your estimate, once the team determines the complexity level of the current effort under consideration.  So as an example, let’s say in your development environment you have determined that user interfaces of low complexity take 40 man hours to develop; medium complexity take 60  hours to develop; and high complexity take 80 hours to develop.  “Complexity” is subject to your own definition and should be documented with the applicable factors in a complexity model.  As your team recognizes that a medium complexity interface will be necessary for the employee training project, you would plug in 60 hours for that unit of work. 

All of these high level units of technical work are grouped together with the scope feature sets they are required by.  Along with each one, the team records the man hour estimate (according to the complexity model), as well as resource type required to perform it – i.e. database administrator or web developer or report developer, etc.  What this allows you to do is aggregate man hours by feature set, or by resource type – depending on how you need to deliver estimate information. 

If you have limited resources (and who doesn’t?), you can even give a crude sense of the calendar time required as you level the hours with the number of resources you think you will actually have available to deploy on the project.  This is not schedule development, mind you, but what I would call “macro scheduling”.  You are definitely not issuing a completion date because that is dependent on the start date which is usually dependant on many other things that are not certain at this point.  The detailed schedule also requires detailed tasks or activities and their dependencies which are also not yet developed until the WBS is completed.  But by taking the total number of man hours for each resource type, and dividing by the number of estimated work resources of that type available; you can determine the approximate elapsed “calendar” time for that activity type.  Then by sequencing any natural dependencies, such as database design work preceding development, then adding up the longest path, you can determine a rough estimate of calendar time for your work effort. 

So, let’s see what all this looks like in our employee training project example: 

Feature Set:  Screen interfaces that facilitate employee registration for training classes

  • Abstract Work Unit: Employee information definition tables
  • Complexity:  Medium
  • Man hours: 40
  • Resource Type:   DBA

 

  • Abstract Work Unit: Training Class information definition tables
  • Complexity:  Medium
  • Man hours: 40
  • Resource Type:   DBA

 

  • Abstract Work Unit: Training Class Maintenance User Interface
  • Complexity:  Medium
  • Man hours: 60
  • Resource Type:   Web Developer

 

  • Abstract Work Unit: Employee Maintenance User Interface
  • Complexity:  Medium
  • Man hours: 60
  • Resource Type:   Web Developer

 

  • Abstract Work Unit: Training Class Registration User Interface
  • Complexity:  Low
  • Man hours: 40
  • Resource Type:   Web Developer

 

Total:  80 DBA hours; 160 Web Developer hours = total 240 man hours.  You can give a blended rate cost or if your different resource types have different hourly rates, you can give a more accurate resource cost since you have the hours broken out by resource type.

If we have 1 DBA and 2 web developers available; since all the database design work must generally be done before much development can be done, in a crude sense with thumb in the air we can say that the job can be done in roughly (80 hrs / 1DBA) + (160 hrs / 2 web developers) = 2 weeks + 2 weeks or 1 month. 

Involving the technical team in an exercise such as this early in the process helps create a high sense of legitimacy to a planning estimate.  By tying the abstract work units to their associated scope feature sets, you set the stage for traceability on the project, without imposing an unduly burdensome exercise.  In addition this level of documentation adds substance and credibility to the estimates quoted and referencing the metrics from past projects adds merit as you communicate to sponsors.  Probably the best benefit however, is that it is an early teambuilding activity and facilitates buy in of the schedule and project plan by the team.

Posted in Estimation, Project Methodology
Tags: , ,
No Comments

Techniques for Creative Team Thinking: Affinity Diagrams, Brain Writing and the Plus/Delta Technique

January 27th, 2010 Susan Dodia

In my last blog, I talked about the Nominal Group Technique, a quick and painless way to guide your team through a brainstorming task.    Each team member gets a stack of Post It notes (or index cards or scraps of paper or whatever is available) and 5 or 10 minutes to silently and anonymously write down as many ideas as they can think of, with one idea per note card.  When the time is up, the meeting facilitator (i.e., the Project Manager – you) collects the artifacts, reads them all aloud, and, once all the ideas have been heard, asks the group to begin discussing them.

There are many benefits to this exercise:

  • Participants have time to organize their thoughts and are not influenced by ideas from others
  • Participants are less emotional when writing down their ideas
  • Less assertive team members are heard equally with more dominant members
  • Ideas are de-personalized because they are submitted anonymously

 Today I will give you some additional methods to use with the Nominal Group Technique (NGT), to maximize the many benefits of using this simple tool. 

Affinity Diagramming is a useful technique for organizing ideas that are generated using NGT.  After all of the ideas the team has generated have been read aloud, put the Post It notes or note cards on a table and ask the team to categorize them into related groups.  Some practitioners believe this exercise should be done silently, with team members arranging and rearranging note cards until everyone is satisfied that each idea is sorted into correct groupings.  Others believe it is acceptable for the team to discuss what they are doing.  You can make the best choice for your group based on your history with them and your understanding of their group dynamics. 

However you choose to do it, this allows ideas to be grouped into categories and then sub-categories, and gives your team a broad framework for their detailed discussion of the ideas they have generated.   

The Plus/Delta Technique is an approach for guiding a discussion about ideas that have been generated using NGT.  As the brainstorming session progresses, ideas will be analyzed and evaluated, to determine which ones will become part of an action plan, or left on a parking lot list, or discarded entirely.  A short list of ideas will be selected for detailed discussion.

During this part of the meeting, divergent opinions emerge and participants may become entrenched in the belief that an idea is either “good” or “bad”.  The Plus/Delta Technique is a straightforward means to make sure your team open-minded about the relative benefits and drawbacks of a particular idea. Simply go around the room and ask each participant to name a benefit (Plus) and a drawback (Delta) of the idea under discussion.  This forces each person to acknowledge both the merits and the flaws of an idea, and can move your group past a conversational deadlock.  

Brain Writing is a variation of NGT.   Instead of having each participant write down all the ideas they can think of in the allotted time, ask each participant to spend 1 or 2 minutes and write down three ideas. 

At the end of the time, each person passes their three ideas to the person on their right.  That person must contribute three ideas by either adding to the ideas that have been passed to them, or to create new ideas.  At the end of the time, each person passes all the cards in front of them, up to six cards, to the person on their right.   Post It Notes are really effective for this technique, because ideas can be stuck together and passed in a chain.  Continue passing the notes and either building on ideas or creating new ones for a few rounds, until the chain of ideas becomes unwieldy.  

When the exercise ends, have your team use Affinity Diagramming to organize the ideas.  This is a great tool to have the team collaborate without initial discussion, and can be effective at overcoming a variety of challenges with how a group interacts with each other.  Participants that don’t know each other well or have a history of competitive behavior may be able to collaborate more successfully using this technique. 

In my next blog I will talk about using Attribution Analysis as a team brainstorming technique.

Posted in Brainstorming, Communications
No Comments

Is it bigger than a breadbox?

January 20th, 2010 Cindy Vandersleen

One of the most perplexing dilemmas of any project portfolio process, a catch 22 really, is how to estimate the size of the potential candidates being submitted before the selection board.  The catch 22 is that the selection committee wants an estimate of how much the project will cost before they can make a decision on whether to approve of it.  However, no work has been done on the project yet to define the scope or requirements to know what work would be necessary.  In fact the team that could even do the estimating has not yet been assembled.  No one wants to even invest the time to do any discovery until they understand the overall cost of the project.  So, if you are a program manager, you argue, it is impossible to determine a reasonable cost.  The decision makers counter-argue that they cannot make a decision without some kind of budgetary number to consider.  So you assemble a technical team and ask them to give you some kind of ballpark estimate based on the very sketchy facts you have at such an early point in the project.  They of course protest, suspicious that they will be held to the number when requirements balloon later in the project.  And round and round you go …

There is no silver bullet answer to this.  You cannot get a high quality detailed estimate without detailed requirements.  One simple approach to this however, is to not try to over think things at the project selection stage.  It is an established fact that estimates have a greater degree of risk and less certainty earlier in the project when less is known.  Rough order of magnitude (ROM) estimates made during project initiation can have margins of error in the range of +-50% from actual.  As the project progresses and knowledge increases, the risk goes down and the margin of error on the estimate decreases to as little as -5 to +10% when all the requirements are hammered out.  So beating the team up to get a binding estimate at the beginning is futile and the selection committee should be educated on that.  A technique that works better is using range buckets.   The ‘McDonald’s approach’: i.e.  - small-medium-large works very well for this.  Usually a project request has been documented briefly with some amount of information regarding high level purpose and objective, business need and justification.  Based on this, a technical resource should be able to slot the project into one of 3 possible ranges or buckets such as:

 

Size

Man-hours

Cost (Avg $70 /Hr)

Weeks

Resources

Small

0 – 1500

$0.00 – $105000.00

0 – 12

1 – 3

Medium

1000 – 5800

$70000.00 – $406000.00

12 – 24

2 – 6

Large

>6000

> $420000.00

> 24

 

  > 6

 

The actual numbers associated with small, medium, and large, can of course be adjusted to whatever makes sense in your organization.  This first estimate should be understood to be within some amount of error, depending on the detail in the project request, but enough to determine approval.

We like to re-visit estimates twice more during the project.  After the scope baseline has been defined, a second estimate, considered a “planning estimate” is developed.  This should generally be between 10 – 25% from actual. The third time is after detailed requirements are developed and clarified between the business and the implementation team.  That is when the team should achieve the -5 to +10%  accuracy.  The rule is, at each of these points if the new estimate varies significantly from the understanding of the project steering (approval) committee, the team must seek permission to continue, or make adjustments to scope to get back to the cost in the original estimate.  That way the team is protected from being saddled with work they didn’t get funding for in the original estimate, and the sponsors stay in control of costs.

Posted in Estimation, Initiation, Project Methodology, Selection
Tags: , ,
One Comment

Techniques for Creative Team Thinking: Nominal Group Technique

January 14th, 2010 Susan Dodia

If you are like most people charged with running a meeting, you find the same group dynamics are in play meeting after meeting after meeting.  You have someone who won’t talk and another who won’t stop talking and everyone else falls somewhere in the middle. 

Dr. Paul Paulus at the University of Texas at Arlington has studied and written about group task performance and creativity.  He has determined that groups are less productive than individuals, if left to their own devices. 

Reasons for this “production loss” are many and include social loafing, the phenomenon of people making less effort to achieve a goal when they work in a group than when they work alone and free riding, the phenomenon of participating without actually contributing anything, (“Great idea, Bob!”). 

Social Interaction Anxiety is the term used for what is happening to your brilliant technical resource when he becomes tongue-tied and inept when asked to participate in a group brainstorming exercise, even though he can toss out brilliant ideas for hours when he is alone in your office.  He is afraid of having his ideas judged and evaluated by a group. 

Other challenges are simply inherent to working in a group: it’s hard to listen to everyone else’s ideas while thinking of your own.  Someone trying to capture the ideas as they are tossed out caused the conversation to slow down.  There are often different power levels represented in the group, and some people may feel intimidated.

However, if a skilled facilitator intervenes (that’s you, Project Manager!), groups can be every bit as productive as individuals when working on creative tasks. 

The simplest way to overcome many of the drawbacks of trying to brainstorm as a team is the Nominal Group Technique (NGT).  This is so simple you have been doing it for years; you just didn’t know it had a name!  In its simplest form, NGT involves handing everyone in your group a stack of Post It notes and giving them 5 or 10 minutes to silently and anonymously write down as many ideas as they can think of, with one idea per Post It.  When the time is up, you collect the Post It Notes, read them all aloud, and, once all the ideas have been heard, ask the group to begin discussing them.

Now, can something this simple really be effective?  Yes, it can.  First, the real or perceived barriers felt by low power members of the group or by sufferers of Social Interaction Anxiety are removed, when ideas are generated anonymously.  Outbreaks of Social Loafing and Free Riding are restrained because everyone is responsible for generating their own Post It notes.   And there is no loss of enthusiasm while a scribe laboriously writes down each idea, because they are already documented by each individual.

Use the ideas on the Post Its as the basis for your “guided” brainstorming session, and you may just get better results.  In my next blog, I’ll talk about additional techniques for using the output of the Nominal Group Technique to get even more out of your team’s brainstorming efforts.

Posted in Communications, Project Performance Improvement, Team Dynamics
No Comments

WBS – Why Be Scared?

January 6th, 2010 Cindy Vandersleen

Some people think of those 3 letters and hold up the sign of the cross as if to ward off vampires.  For some reason this seems to be one of those areas of project management work that meets with more resistance than most from beginning practitioners.  I’m often asked “Do we really need to go to all the trouble of creating one of those?” There seems to be confusion about what a WBS is and why anyone would need one, and generally speaking a lot of fear about the effort involved to prepare one. 

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.

Requirement ID

Requirement

Objective Number

Objective
101 Applicant Tracking system shall support resume filtering according to preset criteria 1 Reduce the amount of time recruiters spend reading and filtering resumes
102 Applicant Tracking system shall support questionnaire and application submittal at time of resume submission to collect all necessary information 2 Reduce the amount of time recruiters spend corresponding back and forth with candidates collecting information
103 Applicant Tracking system shall store all applicant resumes in an online database 3 Improve our ability to file and locate candidate records

 

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:

 

WBS Item

WBS Description

Requirement Number

Requirement
1.1 Setup Requisition Filter options 101 Applicant Tracking system shall support resume filtering according to preset criteria
2.1 Configure Resume Storage facility 103 Applicant Tracking system shall store all applicant resumes in an online database
2.2 Setup Filtering Options 101 Applicant Tracking system shall support resume filtering according to preset criteria
3.0 Build Questionnaire 102 Applicant Tracking system shall support questionnaire and application submittal at time of resume submission to collect all necessary information
4.0 Setup employment application 102 Applicant Tracking system shall support questionnaire and application submittal at time of resume submission to collect all necessary information
5.1 Test requisition 101 Applicant Tracking system shall support resume filtering according to preset criteria
5.2 Test resume Capture 103 Applicant Tracking system shall store all applicant resumes in an online database
5.3 Test Questionnaire 102 Applicant Tracking system shall support questionnaire and application submittal at time of resume submission to collect all necessary information
5.4 Test employment application 102 Applicant Tracking system shall support questionnaire and application submittal at time of resume submission to collect all necessary information
6.0 Project Management All  

 

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.

Posted in Project Methodology, Scope, WBS
Tags: , , ,
2 Comments

Techniques for Creative Team Thinking: De Bono’s Six Thinking Hats

December 31st, 2009 Susan Dodia

My New Year’s Resolution is to focus on creativity this year.  Even though today is only December 31, there is no time like the present!  So, let’s get started. 

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.

Posted in Communications, Project Methodology, Project Performance Improvement, Risk, Schedule Development, Scope, Team Dynamics
2 Comments

Slow down for that Tollgate!

December 23rd, 2009 Cindy Vandersleen

In the hectic pace that can set in on projects, in spite of our best intentions in the beginning, we often find ourselves racing frantically through the end of one phase of work right into the next – especially if we’re a wee bit behind schedule and need to catch up.  Don’t do it!  Take the time to stop and assess the work effort in a tollgate phase review.   Neglecting to get formal stakeholder approval of the work can backfire later in the project.

A tollgate phase review is held at the end of a phase of work and allows stakeholders to review progress and status of the work.  Usually a definitive and limited group of “voting” stakeholders is designated to approve of the work performed thus far, and make the decision about whether the team is ready to move forward to the next phase or stage of the project.  Like a good cocktail party, it’s all about who is there.  The voting stakeholder group is very critical, so they must be chosen carefully so that no one can later claim they didn’t get a warranted vote.  The voting cannot be done with a quorum.  All voters must be present or send a delegate who is authorized to vote and speak on their behalf and is briefed to do so.  In addition to the voters, the project manager, (who may or may not be the meeting facilitator), and the project team are present.  Other non-voting stakeholders may also be present.

The process is done in real time – i.e. no one phones in their vote ahead of time or after the fact, and people make their comments in front of everyone in the meeting.  This prevents hiding behind anonymity and tends to bring out better behavior in people.  No one is allowed to vote simply – “No”.  If they wish to vote No, they must also add what it would take to get to yes, and that must be in very clear, actionable terms.  This tends to get stakeholders to formally approve or state objections.  It tends to be a “speak now or forever hold your peace”; “put up or shut up” moment.   At the end of the voting, the facilitator can solicit general comments and praise for the work efforts of the team – regardless of the decision.   If done well, the tollgate review can be a beneficial teambuilding event, formally giving credit and praise where due.  The trick is how to construct the meeting.

To prepare for a tollgate meeting, the facilitator should document the high level objectives of the phase.  Here again you should take care with this step as this should be backed up with the artifacts of your project.   It is better to be thorough than to be embarrassed by having someone call out an objective later that you forgot about and have neglected from your list.  For each objective, you should state whether the team met the objective according to the original plan, according to an approved alteration to plan, or did not meet the objective.  Presumably, if there are objectives that have not been met, and the team is scheduling a phase review asking for permission to proceed to the next phase; there is a viable scenario such as deferring the objective to a later phase; or cancelling the objective; etc.  Capture any relevant notes/proposals that apply next to each objective.  Below is an example of objectives for a project planning phase:

Planning Phase Objective

 A:Met as Planned;

B:Met approved change to Plan

C:Did Not Meet as Planned

Comments
Scope Statement A – Met as Planned  
WBS A – Met as Planned  
Schedule A – Met as Planned  
Quality Plan A – Met as Planned  
Communications Plan A – Met as Planned  
Risk Management Plan A – Met as Planned  
Risk Register A – Met as Planned  
HR Management Plan C – Did not meet as Planned Due to HR Dept changes to Performance review Stds, we are deferring to next phase in order to incorporate new standards.
     

 

At the beginning of the meeting, the facilitator should prepare a presentation that walks the participants through the process, and then presents a table like the above to review the work of the phase.  Then the facilitator polls each of the voters and captures their vote in real time, along with comments.  Remember, if they vote No, they must also supply what it would take to get to Yes.  The vote tally and capture sheet could look something like this:

 

Name

Vote

Comment
Mary Yes  
Tom Yes  
Sue No Would like to see at least Roles and Responsibilities sections of the HR management plan finalized.  Then I would be OK approving.
     

 

After all votes and associated comments are captured, anyone attending is invited to make a comment about the work effort during the preceding phase and these can be captured in the tally chart as well:

 

Name

Vote

Comment
Mary Yes  
Tom Yes  
Sue No Would like to see at least Roles and Responsibilities sections of the HR management plan finalized. Then I would be OK approving.

General Comments
Jim   The team did a great job in planning.
Sally   Excellent Results!

 

Capturing all this data and commentary during the phase review leaves no doubt where the team stands and gives you concrete evidence that you have permission to move forward.  It can eliminate the capitulation down the road.  It also gets the team what is usually some well deserved recognition for hard work done.

Posted in Project Methodology, Stakeholder Management
Tags: , , ,
3 Comments

Building a Creative Project Team

December 17th, 2009 Susan Dodia

It’s that time of year again.  Whether you believe in New Year’s Resolutions or not, most people are reflecting on the last year and thinking about what we might do differently in the coming year. 

My goal for 2010 is to think more creatively.  Every organization, including my own, is challenged with doing more with less.  We are dared to increase sales, revenue, customer satisfaction or efficiency, while reducing costs, headcount, and anything else that can be reduced. Finding a new way to think seems like the easiest, and most cost effective, way to come up with some new solutions.   

So I will be blogging about team creativity over the next few weeks, to share ideas and best practices for helping your team achieve their creative peak.  Maybe you will find an idea that you can use to help your team work differently.  But first, let’s look at the symptoms and causes of team complacency.    

In his book Team Troubleshooter: How to Find and Fix Team Problems, Dr. Robert Barner says “Complacency can be particularly damaging to teams… because creative thought powers exceptional performance. Its effects are subtle and insidious, for unlike many other team problems, the lack of innovation shows up not so much in errors, rework or damage to interpersonal relationships but in ideas and action plans that are mediocre and unimaginative.  If left unchecked, this problem will restrict the scope of a team’s activities, and the team may never realize its full performance potential.”

Symptoms

Dr. Barner identifies the following symptoms of teams that are in a creativity crisis.  Is your team exhibiting any of these signs?

Lack of Confidence in Ability to Meet New Challenges: Teams that are struggling with complacency often lose their confidence, so new challenges are approached with panic, rather than eagerness.  This panic blocks the ability to come up with creative solutions, and a vicious cycle begins. 

Ignorance of Cutting-Edge Technology and Work Methods:  “Teams that lack innovation not only fail to continually refine and strengthen their technical skills but are often unaware of cutting-edge developments in their particular professions”, Barner says.  Even if they are aware of new developments, the lack of confidence mentioned above may prevent them from actually implementing something untried. 

Mundane Solutions and Redundant Actions: Teams that aren’t comfortable thinking creatively will try to re-use solutions that worked in the past, regardless of the requirements of the current challenge.  Barner observes “Their automatic, by-the-numbers remedies may prove totally inadequate for unique and unusual challenges, such as entry into a totally new product or service area.”

Missed Opportunities: Barner notes that “Complacent teams often fail to anticipate and exploit new opportunities”.  The PMBOK talks about strategies for positive risks, but think about the last time your project team focused on exploiting a positive risk.   Is your team confident enough in their creativity to really put effort into gambling with a positive risk?

Defections in the Ranks: Have you lost any of your best people?  “Sharp, creative professions are attracted to work environments that inspire innovation”, Barner says.  Not being part of a inventive, resourceful project team is an employee satisfaction issue and can cause team members to look for greener, more inspired, fields.  

Causes

Here are some causes for lack of innovation identified by Barner.  Are any of these conditions affecting your team?

Insular Views: Creativity breeds creativity, and teams need access to other people and ideas to perform at their best.  “Some teams suffer from a type of organizational inbreeding that provides little access to ideas and individuals outside their organizations”, Barner says.  “The most isolated teams are usually the ones with the greatest deficits in creative thinking.”  Are your team members active in their professional communities?  Are they exposed to new ideas with any regularity?

Consequences That Discourage Risk Taking:  Does your organization reward risk-taking?  Teams that fear punishment for trying something new will naturally be hesitant to try new things.   

Censorship: “Within some teams, the team leader or selected team members exert subtle but powerful control over the team’s innovative thinking process”, Barner says.  “New or junior-level team members are reluctant to express new ideas and have great difficulty obtaining a fair hearing for their ideas”.  Observe your next team problem-solving session and see what indirect power dynamics are at play.    

Lack of Challenge:  Does your organization have high expectations for your team?  Does your team know what the competition is doing and how their work fits in to the organization’s strategy?  Is your team appropriately utilized?  “Innovation requires a work climate that compels teams to leap beyond barriers to problem solving and explore totally new approaches to their work”, Barner notes. 

Limited Interaction:  Is your team working with other parts of the organization?  Do they feel connected to their customers, partners and stakeholders?  “Innovation is a synergistic process that thrives within work environments where team members learn from and build on one another’s ideas”, Barner observes.    

In my next series of blog posts, I will discuss treatments and techniques for helping your team improve their creative problem solving skills in the New Year.

Posted in Communications, Project Performance Improvement, Team Dynamics
One Comment

Recognizing the achievements that yield success: – The Public Relations of Project Management Part 5

December 9th, 2009 Cindy Vandersleen

In our previous installment of this series, ‘Plan your communications with your “wins” in mind’,  we talked about how to plan and set up vehicles for heralding successes or “wins” as they occur on our project as we do our communications planning.  In this final article we’ll now discuss opportunities to be mindful of as your project progresses so that you have great material to feed into these PR machines you have set up.

  1. Schedule Milestones – each week you will undoubtedly observe a cadence and rhythm of activities including team status meetings and distribution of status reports or updating of dashboards.  As important milestones are achieved, be sure to point this out and credit the team responsible.
  2. Quality Objectives - Throughout the project quality goals will be measured and as they are achieved either through the use of automated or manual tests, these are also great things to herald with testimony if available to add a human perspective.
  3. Risk Management – Each week in the weekly team status meeting, the team should be reviewing the risk register and monitoring previously identified risks to update status if necessary, and capture and assess any newly identified risks.  As risks captured on the risk register get closed, advertise this in your PR vehicles and really crow about it.  This is some of the most important work you can do to achieve success on your project.
  4. Issue Management – Similar to risks, each week in the weekly team status meeting, the team will be reviewing the issue log.  As large or key issues get closed out, these are also great things to make noise about in your PR vehicles.
  5. Tollgate Phase Reviews – At the end of a project phase, it is a good practice to conduct a phase review in order to receive approval from your sponsors or steering committee to move forward.  This usually involves a facilitated process where votes and comments are tallied and captured.  When done correctly, this can be a great teambuilding experience regardless of the decision because the facilitator ends by soliciting comments on the work effort.   There are almost always positive comments issued about the efforts of the team and these make wonderful material for the PR vehicles.
  6. Lessons Learned sessions – These are conducted at the end of a project or at the end of a phase to review the work done in order to determine if any adjustments are necessary in the processes.  The team evaluates what went right, what went wrong, what needs to change and documents for the future.  The positive lessons (i.e. what went right), is of course great PR material, but even the negative lessons can be spun in a positive way.  They are mistakes that won’t be repeated in the future and can have significant as well as quantifiable benefits – such as cost savings, increased productivity, more efficient procedures, safer environment, or improved employee morale.

 So, as you wear your chief PR officer hat on your project and you move through your project, look for the above activities and accomplishments and advertise them promptly as they happen.  It may very well be what keeps your project or engagement funded.

Posted in Communications, Project Methodology
Tags: , , , , , , , ,
No Comments

Improving Project Team Accountability

December 3rd, 2009 Susan Dodia

Communicating about tasks, roles and responsibilities takes up a great deal of time for most project managers.  After communicating, a project manager documents and tracks task assignments in a project plan.  So everybody has something to do, and the plan forward is clear to all.  But how do you translate those task assignments into a real sense of ownership by individual team members?  How do you make sure that each member of the project team feels accountable for the project’s success, not just the project manager?

In his book Team Troubleshooter: How to Find and Fix Team Problems, Dr. Robert Barner says teams that are struggling with accountability issues often display the following symptoms:

A Focus on Activities, Not Results: Who among us doesn’t relish the idea of updating a project plan to show that a task or even a sub-project is complete?  But are these completed tasks actually accomplishing anything except improving the project’s “percent complete” column?  As Barner says “activity-based evaluations can easily fool teams into believing they’re making valuable organizational contributions when their employers are actually deriving little from their activities”.  As project managers, we must ensure our project teams focus on the end results, not the task victories, in order to provide real value to our organizations. 

Lack of Direction or Motivation: Project team members who are working from a comprehensive project plan which is reviewed and updated frequently should be well aware of the direction of the project.  But motivation is another story.  A project plan can contain thousands of tasks that team members diligently plod through.  But are they aware of the results of their efforts? 

“It’s hard to stay interested in a game if you can’t tell the score.  Team members who are trying to function without solid measurement systems are often unmotivated and apathetic.  Well-designed scorecards help team members focus on the most important work activities” Barner advises. 

So if your team is struggling with accountability issues, think about what you are using to report project progress.  You may find that the standard project reporting is too broad and diffuse to be able to inspire your team members.  You may need to tie milestone information to another metric within your organization, like costs, usage, time to market or customer feedback, in order to keep your team’s “eyes on the prize” and ensure that your team understands their contributions to the larger organization. 

Difficulty Recovering From and Analyzing Setbacks:  Risk management is a huge part of project management, and many of us have seen a team devastated by an unanticipated or under-anticipated risk.  This is particularly challenging for teams that have made risk management a priority through frequent reviews of risk events, their probabilities and impacts, and who have invested the time in creating and maintaining project risk artifacts. 

“Even the best teams encounter occasional performance setbacks.  When faced with reversals, teams with reliable scorecards in place are able to put the situation in perspective by reminding themselves of the steady improvement they’ve made over the long run”, Barner reports.

This is where a mid-project Lessons Learned session becomes valuable.  When your team suffers a setback, use those risk documents to get a realistic view on what went wrong.  Bring your group together to discuss what went wrong, what went right and how to do it better in the future.  Learn from it and then move on. 

Henry David Thoreau said “Aim above morality. Be not simply good; be good for something.”  From a project manager’s perspective, this means sharing accountability with your team by focusing on business, not just busyness!

Posted in Communications, Risk, Team Dynamics
One Comment