My PMI-ACP Book is coming along nicely and today RMC released some more content including sample questions and walked through explanations of the answers. Visit the RMC Site to access it and also sign up for future previews and special discounts.
Now if I could only write this stuff as quickly as they are giving it away, I would be doing OK!
I am overdue for providing an update on how my work on The PMBOK v5 Guide is going. Well, it is on its way. The process is slow (sometimes painfully slow) but this is because of the number of people involved and the review process used. To give an idea, here is the plan for the next 6 months:
* 17 February – 20 March 2012: the exposure draft PMBOK® Guide – Fifth Edition will be open for comments
* Late February 2012: team training for our adjudication processes
* 20 March 2012: our exposure draft period closes and comment adjudication begins
* 20 March – 28 April 2012: teams adjudicate exposure draft comments
* Early May – mid May 2012: core committee reconciles any comment adjudications that cut across chapters or where consensus has not yet been obtained
* Mid May – early June 2012: appeals period for adjudication decisions; final draft QC and integration reviews
* Early June – mid June 2012: appeals adjudication and resolution
* Mid June – late June 2012: final draft cleanup and incorporation of QC comments
* 28 June 2012: core committee vote on finalized draft
The Exposure Draft process is a great mechanism for allowing members to review and comment on new material, but likely to generate a ton of review work for us. The Fourth Edition update, back in 2008 received over 4,400 comments during its exposure draft. Since the membership of the PMI has increased significantly since 2008 we could be looking at close to double that figure.
That is a lot of suggested changes to review and I think March and April will be a busy time for me. Of course they will not arrive in one Word document, but I wonder what the PMBOK Guide would look like if we just did an “Accept All”? Right now it is the calm before the storm; I am going to make the most of it.
SMEs, SM0s and the Deluded Developer Day
We all want Subject Matter Experts (SMEs), but what happens if we get a Subject Matter Zeros (SM0s)? How does that impact your schedule, and what about team members who have “other project commitments”? Before you know it, that 6 month schedule that looked pretty comfortable, is looking like a fairy tale.
I recently attended a great presentation by Lee Lambert at my local PMI conference and while he was not talking about agile per say, his commentary on SMEs and part time resources struck a chord, which I would like to share.
The role of the customer, the business, the Subject Matter Expert (SME) on agile projects is vital. They not only help provide requirements, but also clarify details, validate prototypes, perform UAT, tell us about business changes, articulate the goal, prioritize, the list goes on. Great SMEs are like great multi-disciplined developers who can do BA work, architecture, development, and QA – they can just make projects happen. It is rare to get these mythical beings, but I have been fortunate to work with a few.
More commonly we work with SMEs with limited time who have a preference for one or two areas of work, such as providing requirements or testing increments of software. We obviously want the best SMEs we can get, but the best people are always busy since they “get-it” and can crank out work – so who wouldn’t want to engage them?
When SMEs are not available we can assign proxy customers, where perhaps a BA plays the role of the customer, or we get someone more junior from the business who may be less experienced in the role than ideal. These are just the realities of working in companies today and as the Rolling Stones said, “You can't always get what you want, But if you try sometimes you just might find, You get what you need”. When this happens we just need to be sure we understand the consequences to our schedule.
The other factor is team member availability, ideally this is 100%. This makes face-to-face meetings easy, resource leveling a breeze, and a one day task often does actually get done in one day, imagine that! “You, you may say I'm a dreamer, but I'm not the only one”, many project schedules are planned this way even when commitments for support and other projects take availability from the project.
Overall Task Duration is dictated by the productivity of our resources along with their availability, as follows:
So if a task was estimated at 8 hours (one day) for our SME & Dev combo, but we did not get the SME we wanted and instead got a SM0 who, lets optimistically assume is 50% as productive as our SME. Also the developer is not 100% committed to the team, but split across 2 projects and also providing production support for those projects, then their true availability for new development on our project might be only 25%.
Using these figures for our 8 hour task we get:
This result can be surprising, we instinctively knew it would take longer since the business involvement was not perfect and the developer had other work, most PMs factor in 3-4 times longer, maybe 5-6 times, but it is rare for the full 8 times longer to be properly incorporated.
This is why ideas like Yesterday’s Weather (gauging performance based on previous results) and measuring team capacity via Velocity are often better predictors of completion rates. The other point it illustrates is the impact and significance of suboptimal resources and non-dedicated participants.
As always the best time to influence project durations and success factors is when selecting the people for the project. It is a too easy to overlook the true impact of a few small compromises and not properly explain the consequences that then accumulate to make projects late. We can use the Task Duration formula to illustrate this or rely on the Beatles “Help, I need somebody; Help, not just anybody, Help…”.
Bio: Mike Griffiths is a project manager who seriously needs to update his music collection. He has served on the board of the Agile Alliance and the APLN. Mike is a contributor to the PMBOK v5 Guide, the Software Extension to the PMBOK Guide, the PMI Agile CoP, and the PMI-ACP Steering Committees.
This post first appeared in Gantthead.com here.
I will be presenting on “Smart Agile Metrics” at the upcoming Calgary Agile Methods User Group (CAMUG) meeting Tuesday January 10th.
Here is the outline:
“Collecting and reporting effective metrics can be a tricky business. Einstein captured it well when he noted "Not everything that can be counted counts, and not everything that counts can be counted".
Software projects have a history of measuring irrelevant and even counter-productive progress tracking metrics. The "Hawthorne Effect" should teach us that we will influence what we measure, yet companies continue to overtly track things like hours worked and lines of code written, unaware that they send the message of valuing long hours over results, and discourage simplifications and healthy refactoring. Quite often the metrics we want to track are intangible and subjective and so people tend to shy away from them.
More fundamentally, why are we even tracking these metrics? Is it to report on what has already occurred or help steer our future course? Often an imperfect view of the future is more useful than a perfect view of the past. The accuracy of hind-sight and our attraction to certainty often creates too much of an emphasis on lagging, already occurred measurements compared to leading metrics. So we get fancy graphs of project spend and defect rates, but no better insights into what we should be doing differently in order to meet our goal.
In this presentation I will review many common project metrics and explain why they are largely misguided and counter productive. An alternative set of "Design Factory" metrics will be presented that are "simple and relevant to the true project goal", these metrics leverage the Hawthorne effect and focus on leading metrics to support smarter decision making.”
This is a favourite talk of mine that I presented many times, just never for CAMUG before. I have written this post on some of the concepts in the talk. The event is free to attend and hosted at the University of Calgary. I am looking forward to seeing some familiar faces and meeting some new people too, I hope you can make it along if you are in the area.
Location: ICT Building Room 121
Time: 6:00-6:30pm Snacks,
6:30-7:30pm Presentation