Thanks to a newsletter I receive from Openview Labs, this morning I was introduced to a blogger I have not read before, Richard Lawrence. He is a certified SCRUM coach and writes about software development and making software teams happier and more productive. Openview cites a recent article written by Lawrence suggesting that development teams should focus more on being predictable than being productive. He argues that increased productivity will fall out of a predictable approach to software development.
Although Lawrence is writing about software development specifically, I believe that what he’s suggesting will apply to any kind of project-based work. In fact, his assertions remind me of the old story of the tortoise and the hare. Slow and steady (predictable) wins the race.
Lawrence suggests that a focus on predictability drives a team to:
- Develop and complete smaller projects that can be completed in a day or two. I like the idea of breaking the work up into smaller, bite-sized, chunks. Although there will always be larger projects with time-lines that stretch out to months or even longer, breaking up those large projects into shorter durations with complete-able deliverables allows teams to show value at more regular intervals. This is good for stakeholders, team morale, and ultimately project success.
- Work on a smaller number of project deliverables at once. I once worked with a fellow who was incredibly productive if he had a couple of project deliverables on his plate at a time. Less than that and he would fuss over a project deliverable forever—more than that and he would be so overwhelmed that he would freeze up and accomplish very little. Admittedly, every team member is different, but keeping expectations reasonable (in my opinion) helps project teams be more productive.
- Ensure that the definition of done that is identified before the project is started is the same definition of done when the project is completed. I’ve noticed that the longer the duration of a project, the more likely the definition of done will morph into something other than what was originally intended. Sometimes this might be the result of scope creep, but often it is the result of unforeseen impediments that over the course of a lengthy project make it difficult to completely accomplish the goals of the initiative.
- Enable individual team members to cross disciplines to get things done, avoiding unpredictable wait times. Shorter duration projects often encourage team members to step outside of their "defined" roles to get things done. Which, after all, is what work management is all about, right?
- Make achievable commitments based on past results. From a management perspective, it’s easier to predict the results of a series of shorter duration projects than it is to predict the results of a project that will drag on for months at a time. From the individual team members perspective, it allows them to feel a sense of accomplishment at regular intervals. Most people respond well to feeling a sense of accomplishment at a job well done. The more often they are able to do that, the more productive they will be.
On the other hand, Lawrence suggests (and I agree), focusing on productivity usually leads to:
- Individuals optimizing for their own productivity (i.e. lots of tasks getting done)
- Over-committing
- Starting projects without necessarily believing they’ll get done in the time-line required
- Sacrificing quality for speed (i.e. "Just get it done; we’ll clean it up later.")
- Communicating and collaborating less ("All that conversation slows me down. I need to focus on my work.")
Lawrence argues that a strict focus on productivity might increase a project teams ability to get more accomplished in the short term, but focusing on predictability is a better long-term solution for helping project teams increase productivity. I have to agree.
Slow and steady wins the race.
Is predictability part of your work management methodology? How do you utilize your project management tools to increase predictability and ultimately productivity?













Funny I just left a comment over on Derek Huether’s blog about the need for consistent and repetitive status reporting. From my perspective, there’s *plenty* of unpredictability on our projects. Waaaaay more than any of us probably want. LOL Designing your project to be consistent, predictable and mundane isn’t a bad thing. It sets a framework that everyone can understand. Then, when things go off the rails in one area, team members are still operating within a comfortable environment to bring things back in line! The more exotic or complex the method, the less likely that is to happen.
Thanks for contributing Geoff. I think predictability is an under-rated success factor. I also agree with Lawrence when he suggests that increased productivity falls out of predictability. Sometimes we tend to look for the most complex or sexy solution, when slow and steady often does win the race.
Pingback: Ancient Greek and Project Frameworks | The Papercut Project Manager