State an estimate as a probability distribution. For this meme: “I estimate an 80% probability of completing in less than 195 minutes and a 20% probability of completing in less than 175 minutes, but the absolute minimum is 170 minutes. I’ll provide an updated estimate in an hour or so. Do you want me to EMail you the assumptions and risk register?”
“Uhhhh … no.” [thinks: WTF did she just say?] “Uh, can you give me that as a single number?”
[stares for a four-count] “The mode was 182 minutes, at 6.3%. Which means there is a 93.7% probability that it won’t take 182 minutes.”
New project management articles published on the web during the week of July 15 – 21. And this week’s video: Elizabeth Harrin recommends her four favorite books on leadership. Less than 3 minutes, safe for work.
Business Acumen and Strategy
Dashun Wang researched the difference in user adoption profiles between an entirely new innovation and a replacement innovation, e.g. the latest smart phone. 4 minutes to read.
John Galyon instructs us on building one of the fundamental documents of project management: the business case. 7 minutes to read.
Jessica Lis digs into regulation and legal liability as it may apply to artificial intelligence agents that damage the physical world. 12 minutes to read.
PMI has just released the Third Edition of the Practice Standard for Work Breakdown Structures. This edition “applies the WBS to the predictive, iterative, incremental and agile project life cycles, while also exploring several different types of decomposition in practice today.” 196 pages, free for PMI members.
Billy Guinan extols the virtues of Sharepoint for collaborative project management, especially when synched with MS Project. 3 minutes to read.
John Goodpasture reflects on the axiom that, “A process, viewed end-to-end, is not better than its worst component.” 2 minutes to read.
Mike Clayton explains the nature of project constraints in a 4 minutes video, safe for work.
Bill Yates explains the changes to the CAPM certification, a more appropriate entry point for aspiring project managers than the PMP. 2 minutes to read.
Elise Stevens interviews Echo Woolf on embracing the art aspect of project management, as well as the science. Podcast, 18 minutes, safe for work.
Brad Egeland walks us through a five-step process for managing compliance during a project, using data security compliance as an example. 3 minutes to read.
Managing Software Development
Stefan Wolpers curates his weekly list of Agile content, from a new book preview to product management for machine learning to coaching the reluctant. 7 outbound links, 3 minutes to read.
Gábor Zöld gives us detailed instructions for creating the culture needed for effective code reviews. With best practices and a case study. 13 minutes to read.
Mike Cohn clarifies the use of Fibonacci sequence or other non-sequential number in story point estimates. Think of these estimates as ranges. 4 minutes to read.
One Man explains defect triage—what it is, why we need it, the process, and so on. 3 minutes to read.
Andy Jordan opines on how the shift from temporary project teams to permanent product teams has changed software development. 6 minutes to read.
Suzanne Lucas suggests ten ways to deliver more specific praise than the generic, “Good job!” 3 minutes to read.
Greg Satell on transformation: “A leader’s role is not to plan and direct action, but to inspire and empower belief.” 5 minutes to read.
David Dye answers a question about when to have a meeting and when to send an Email, instead. Podcast, 9 minutes, safe for work.
Research and Insights
Harry First, Professor of Law at NYU, reviews the Microsoft case from the 1990’s for lessons learned about regulating and litigating Big Tech. 7 minutes to read.
Paul Zak describes the neuroscience findings of how our brains decide when to trust. 8 minutes to read.
Martin Giles explains digital encryption, why quantum computers are a threat to encryption, and the need for post-quantum cryptography. 5 minutes to read.
Nina Xiang curated ten expert predictions for how the artificial intelligence industry in China will evolve over the next decade. Irony alert: human intelligence predicting AI. 5 minutes to read.
Working and the Workplace
Seth Godin suggests that there are really two kinds of change, and we should decide which is needed before preparing our presentation. Just a minute to read.
Kelsey Jones says that all this “busyness” is nonsense, exaggeration, and hype. The cure is better time management, of course. 5 minutes to read.
Frank Sonnenberg cataloged 16 types of toxic people. Now, where did I put those antacid tablets? 2 minutes to read.
I think a lot of us have wondered whether our work breakdown structure (WBS) would seem reasonable to our peers. A Redditor on the projectmanagement subreddit recently asked, “How many rows deep is your typical MS Project plan for a complex project lasting 1 year? Am at 1000 rows now. Am I above or below average?”
I don’t think there is a meaningful “average” to cite because a WBS is based on too many specifics. I think a more actionable question is, “Will this breakdown allow us to communicate the work to be done and assess progress and work remaining?” That said, there are a lot of rules of thumb out there for creating a work breakdown structure (WBS). I find these to be generally useful:
A task should be something that takes from 2 days to 2 weeks to complete.
If you have a small number of tasks assigned to one or two resources that individually take less than 2 days, put them in a checklist and make completion of the checklist a task. Checklists are our friends.
If you have a single task that takes more than 2 weeks, maybe it should be divided into smaller pieces. Agile teams commonly break an epic into two or more stories.
Think in terms of deliverables. If a task doesn’t produce a deliverable or further the evolution of a deliverable, should it really be a task?
If person A produces a deliverable, person B inspects the deliverable, and person C approves the deliverable, you have at least three tasks.
Structuring The Work
A WBS should include three types of entries: detail tasks, describing the work to be done; summary tasks, which group detail tasks on some meaningful basis; and milestones, which allow us to note progress based on completion of selected detail tasks.
A WBS should be in the form of an outline, with two or more levels of indenture. It is common to have a summary task with multiple child summary tasks, and so on. The term ragged pyramid is descriptive of many WBS.
There are two primary audiences for a WBS: the people who will be assigned to perform the tasks (and the people they report to) and project stakeholders who want to understand how the project will affect them. Keep both audiences in mind.
Design your WBS for dependencies. If you have six detail tasks under a single summary task, to be performed one after another, and there is a single dependency running from the summary task to the next detail task under some other summary task, it will probably be easier to explain to both audiences than some rat’s nest of links going all over the place.
If a summary task only has two detail tasks under it, maybe the details should be merged into one of the peers of the summary task, or moved up to the same level as the summary. Similarly, a summary task with so many detail tasks that you have scroll through them might be a candidate for reorganization.
When I have multiple teams working in parallel, I often put each team’s tasks under their own summary task. When they reach a milestone that requires a hand-off to another team, that outbound dependency is located in the top summary task. Especially useful when I have one or more vendors participating.
Considerations for Managing the Work
Make your structure as detailed as needed to facilitate an understanding of the work, but not so detailed that it becomes unmaintainable. If your 1000 row WBS includes 800 or so detail tasks and they average a week in duration, then you will average 16 tasks initiated and another 16 closed out each week over the course of a year. If that doesn’t seem manageable to you, or those assumptions aren’t reasonable, consider your alternatives, from delegating administration of task updates to fissioning into two projects.
If anyone would like to add a rule, or dispute one of mine, leave a comment below.