Archive for June, 2011

Don’t Skip the Review

It’s done.  A picture-perfect set of requirements are documented.  Blood, sweat, and tears have poured into this document – most of them yours but maybe some from your stakeholders along the way.  The next step is to host a review.  Yes, you are going to make everyone involved in building this document (and a few others – keep reading), walk through the documentation one more time.

Yes…. I am serious.  I know the review process may seem like overkill but there are so many reasons to do it.  Before you forget – we don’t live in a black & white world so I do accept the fact that it may not be appropriate for every project so use your judgement but keep some of these points in mind.

One Last Chance

Your stakeholders have provided you with many requirements and insights throughout the analysis phase of your project.  But do you have any guarantee that you have them all captured – or even captured accurately?  A walk-through of documentation gives everyone a chance to talk about any questions or concerns with the documentation as a group.  This may trigger their thoughts on an additional requirement.  A requirement identified in an earlier phase of the project will save you costly time and money if identified later – like in testing or worse, in production.  So yes, it can be costly to pull all stakeholders into a review meeting, but it is more costly to identify scope changes later.

Missed a Meeting – Never Happens

Did every stakeholder participate in every requirements gathering meeting?  No?  Consider me shocked!  Work (and life) happens and you cannot expect everyone to be in every session.  Plus, with other elicitation techniques such as one-on-ones, job shadowing, etc, some people may be left out.  Having a documentation review lets you breakdown silos across teams and gives everyone a chance to hear the requirements gathered.

Now to Make it Productive

Once you believe there is value in hosting the meeting – here are some tips to consider before setting it up.

  1. Do not schedule a marathon review – if your documentation is lengthy, consider breaking up your review in 90 minute or less periods over a short period of time.  Maybe a session in the morning, a break, and then another session in the afternoon.  Perhaps you need to spread it over days – host a session each day.  Putting too much time between review sessions will reduce the value of the meeting as people will lose continuity of the discussion and their ability to focus.
  2. Publish the documentation at least 2 business days in advance – ask for your participants to come prepared with feedback.  Make it clear to them that you will not be reading the document to them word-for-word – so they need to have read the document, and prepared notes for questions or concerns.
  3. Offer flexibility in logistics – face to face is great but not always realistic – offer participants the chance to dial into the meeting if located remotely but keep them engaged in the conversation – not just on mute while they read their email.
  4. Multiple Presenters – I’m sure you have a lovely voice but ask others involved in the project to help host the review.  If there is a section that a stakeholder provided input on, ask them to present that portion of the document.  It will get others actively involved and breaks up the meeting a bit for everyone.
  5. Notes – it is very hard to host a meeting and take detailed notes.  And since this meeting is all about updates to the documentation, notes are important.  Ask a co-worker or stakeholder to help out by taking the notes during the meeting.  If you can swing it, make updates to the documentation as you review the documents.  That reduces your post-meeting work AND lets your stakeholders see your precise updates.

One last point that you might be thinking – yes, you could send out your documentation and ask everyone to read it and provide feedback to you.  Does everyone always do exactly as you ask in the timeframe that you ask it?  If so, I am very jealous!  People get busy – and they don’t get to reading documents related to projects not set to deploy for another 30-120 days.  You also lose out on the rich, interactive conversation that could arise if a stakeholder points out an issue with the documentation.  I also recently saw there some IT team members brought in some complimentary documentation to the review to show the stakeholders – this was a great use of time, in my opinion and helped the stakeholders see/hear that 1) IT was listening, and 2) IT is already moving forward to meet their needs.  Could not happen if the review had not occurred!

Just my perspective but my experience has shown that hosting a requirements documentation (regardless of requirements format – visual, contextual, use cases, etc) review.  What experiences have you had with reviews?  What worked well?  What did not?  Share with everyone so we never have to sit through a boring review again!

Advertisements

June 15, 2011 at 7:21 pm 1 comment

See One. Do One. Teach One.

Television can teach you a lot.  In particular, I think of an episode of Grey’s Anatomy.  In the first season, Dr. Bailey tells a young resident that it’s time for them to take a step forward in their education.  She says “See one.  Do one.  Teach one.”  As leaders, we should all take this as a lesson in employee development.  We owe it to our team members to prepare them for the next step forward in their careers.  Not only does it help them feel more empowered in their role, but it also helps in succession planning.  Growing your replacement is a rewarding activity – especially when you are ready to move on.

Our teams do not need us to coddle them.  They are professional adults.  They need to know that we will be there – have their backs – if they try something new.  I am not saying that they should be hung out to dry – asked to do something that they have no earthly clue how to do.  Once a team member has observed you undertake a particular task, it is time to ask them to take it on next time.  Talk them through how you prepped, the end result that you are looking for, and maybe even some notes on how you would like to do it better yourself (they can learn from your experience).

Once they have performed the task, offer them some feedback.  Compare notes – as you might be able to learn from their experiences.

Next, it’s time for “Teach one”.  Talk to your team member about how they can share their new knowledge with their peers.  This may not happen immediately but it something to consider so others can learn from their experience.  This helps the organization grow in their knowledge and skills, plus it can build team spirit.  Additional benefit – reduce single points of knowledge (including yourself).

Whether you love Grey’s Anatomy or not, hopefully you have an appreciation for these words of wisdom shared by the show.  Please share your experiences with team member development – I’d love to hear about your positive & constructive experiences.

June 8, 2011 at 11:00 pm 4 comments

Using Color on a Project Status – Worthless without Definition

Red, Yellow and Green – infamous colors used for street lights, ugly holiday sweaters and project management status reports.  While I am fundamentally opposed to the ugly sweaters, I am a strong supporter of street lights and project management status reports.  The status report is a critical communication tool.

Project team members and leadership within your company cannot check on project status daily.  Yet they need to stay informed of the overall health of the project.  There are so many ways to do this in a way that is effective for team members, executives, and the project manager.  This post is going to focus on the use of color in status reporting but another day I may have to write a post about how to use the status report (PLEASE do not have a meeting to read your status report….. ).  I would strongly suggest looking into the PMI organization for some good guidance from their PMBOK (Project Management Body of Knowledge).

I understand why so many people are driven to report status based on color.  It’s easy to read, visually easy to recognize, and so many people like to use jazzy little clip art of spotlights on their status report for fun.  But a red, yellow, green status report is as worthless as the crayons it is made with if you do not define what specifically drives a project to be classified by one of these three colors.

All projects involve 3 things – Scope, Schedule, and Cost.  Therefore, a good way to define how you will monitor the status of your project involves these three areas.  You can try to blend these three areas together to report a single “color” status — but I think the overall project is better reported by area for a more complete perspective.

Reporting Status of Scope

Scope is a bit tricky as it is either defined, or not.  A good way to monitor the health of your Scope is to track the number of pending, approved, or rejected change requests (post-requirements approval).  Given that a change in Scope will also (likely) impact your Schedule and/or Cost – this area bleeds into the other two.  I would suggest talking with your Project Sponsor early in the project to define what an acceptable amount of change will be for this project.  This can be hard to quantify but when you consider what the priority of the project is (Scope, Schedule or Cost – only one is most important) – then you should be able to set an objective to manage scope change appropriately.  If Scope is your project priority – then you may expect a high number of change requests.  If Schedule is your priority, you may want to define an objective to only accept X days of additional development into your project through change requests.  If Cost is your priority, then you may state that change requests will be budgeted to stay within X% of your total budget.  Again – this is subjective – just some ideas here to get the conversation started.

So for Scope, in our situation, we may state that the following:

At any point, if the volume of approved change requests is within 0-2% of total budget = the status of the effort will be Green.  Change Requests +2%-6% will be considered Yellow.  Any point when the approved change requests exceed 6%, the status of Scope will be Red.

Fact-based and yet still associated to a color!  Best of both worlds!

Reporting Status of Schedule

This type of status reporting is more native to many project managers.  It’s all about dates.  Most project managers define a WBS early in their project lifecycle.  The idea of reporting status is about using the major milestones in your schedule and noting when you are starting to press against the boundaries that you define early in the lifecycle.

Any major milestone that is not met within 2 business days of the Planned Date will cause for the Schedule to be reported as Yellow.  If a major milestone is not met within 5 business days of the Planned Date will cause for the Schedule to be reported as Red.  Any major milestone that is accomplished prior to or by the Planned Date will cause for the Schedule to be reported as Green.

If, along the way, the project schedule changes (which they so often do) – then just revise your tracking plans as needed.  And make sure you define your own boundaries – I used 2 & 5 business days as an example – it all depends on the Project Priority.  If Schedule is not a significant objective for this project, pick your battles and select windows of time that are appropriate.  Don’t scream that your project is Red because of a missed Major Milestone when, in reality, the Project Sponsor just wants it delivered sometime this year.

Reporting Status of Cost

By now, I’m almost thinking that I don’t need to write anything for this section.  I’m sure that you get the idea….

The status of Cost will be reported as Green if Project Actuals & Project Forecast are within 2% of the Total Budget.  If the Project Actuals + Project Forecast are between +2%-6%, the status of Cost will be reported as Yellow.  If Project Actuals & Project Forecast exceed 6%, the status of Cost will be reported as Red.

In Summary

Hopefully this post is giving you some ideas of why colors are meaningless unless you put some thought behind them.  Too often, project managers apply color subjectively and can get everyone’s attention on a RED project that may be distracting management attention from something else that needs it more.  If you are going to use color, define how it will be applied in advance.  Make it part of your project kick-off so everyone understands how the status will be reported and the color will complement their understanding of the situation being reported on the status.

June 5, 2011 at 9:09 pm 4 comments


Enter your email address to subscribe to this blog and receive notifications of new posts by email.

Join 39 other followers

Top Posts & Pages


%d bloggers like this: