-
When Reality Hits - Project Managers Roll With It
February 11, 2012
-
When IT Is Your Company’s “Piggy Bank”
February 10, 2012
-
4 Key Things a Project Manager Must Do
February 10, 2012
-
Essential Project Management
February 10, 2012
-
8 Traits of Top Project Managers - Part 1
February 9, 2012
-
Agile Project Management - Engaging Your Customer!
February 9, 2012
-
9 Tips to Avoid Traps in Project Planning
February 9, 2012
-
Why Projects Succeed - Executive Sponsorship
February 8, 2012
-
On Customer Participation in Agile Projects
February 8, 2012
-
A Project Charter for Lazy Teams
February 8, 2012
Project Scheduling: 90% Done Is Not Almost Done
September 3, 2009 | Author: PM Hut | Filed under: Project Management Best Practices, Scheduling
Project Scheduling: 90% Done Is Not Almost Done
By Johanna Rothman
Back when I was a new developer, my boss asked me how long it would take to complete a specific task. I looked at it for about 20 seconds, and said “Four weeks.” “Great,” he said.
At the end of the first week, I was 25% done—that’s what I reported on my status report. At the end of the second week, I was 50% done. At the end of the third week, I was 75% done. At the end of the fourth week, I was 90% done. At the end of the fifth week, I was 92% done. At the end of the sixth week, when I reported I was 92.5% done, my manager finally took pity on me.
“Johanna, do you know when you will be done?”
“Nope. Not a clue.”
“Would you like a little help learning how to know when you’ll be done?”
“You bet!”
My manager knew that 90%, 92%, and especially 92.5% done was not anywhere near done. Rather, it was a good clue that I had no idea when I would be done. I’d run smack dab into the 90% Done syndrome.
My manager sat me down and asked me questions that helped me break the large tasks into many smaller tasks. Like most people, I’m good at estimating smaller tasks and not so good at estimating larger tasks. Then, I listed all the test cases I would have to check, to know if this code was done. I didn’t call them test cases back then; I called them “done criteria.” My boss and I both knew that once I’d finished the tasks and made sure my code met the “done criteria,” I would actually be done.
That work took me almost ten weeks to complete. Luckily, I had an understanding manager who helped me plan and test my way out of the 90% Done syndrome.
Here are actions you can take, whether you are the one stuck in 90% Done or the manager of a person stuck in 90% Done:
- List everything you need to do, to finish the big chunk of work. I include any infrastructure work such as setting up branches in the source control system.
- Estimate each item on that list. This initial estimate will help you see how long it might take to complete the entire task.
- Now, look to see how long each item on that list will take to finish. If you have a task longer than one day, break that task into smaller pieces. Breaking larger tasks into these inch-pebbles is critical for escaping the 90% Done syndrome.
- Determine a way to show visible status to anyone who’s interested. If you’re the person doing the work, what would you have to do to show your status to your manager? If you’re the manager, what do you need to see? You might need to see lists of test cases or a demo or something else that shows you visible progress.
- Since you’ve got one-day or smaller tasks, you can track your progress daily. I like to keep a chart or list of the tasks, my initial estimated end time and the actual end time for each task. This is especially important for you managers, so you can see if the person is being interrupted and therefore is multitasking.
Sometimes, people fall into 90% Done because they’re implementing across the architecture, writing all the GUI or writing all of one layer at a time. If you shift people to implementing by feature and have them work in short iterations, they start trying to estimate and complete smaller chunks of work. Their estimates will be more accurate, and they are more likely to finish the work.
This original article can be found at: http://www.jrothman.com/pragmaticmanager/90percentdoneisnotdone.html
Johanna Rothman consults, speaks, and writes on managing high-technology product development. Johanna is the author of Manage It!’Your Guide to Modern Pragmatic Project Management’. She is the coauthor of the pragmatic Behind Closed Doors, Secrets of Great Management, and author of the highly acclaimed Hiring the Best Knowledge Workers, Techies & Nerds: The Secrets and Science of Hiring Technical People. And, Johanna is a host and session leader at the Amplifying Your Effectiveness (AYE) conference (http://www.ayeconference.com). You can see Johanna’s other writings at http://www.jrothman.com.
Related Articles
feel free to leave a comment
Comment Guidelines: Basic XHTML is allowed (a href, strong, em, code). All line breaks and paragraphs are automatically generated. Off-topic or inappropriate comments will be edited or deleted. Email addresses will never be published. Keep it PG-13 people!
XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>
All fields marked with " * " are required.
- Agile Project Management
- Ask the Hut
- Certification
- Change Management
- Communications Management
- Computer Based Information Systems
- Concepts
- Corporate Transformation
- Cost Management
- Critical Chain Project Management
- Delegation
- History
- HR Management
- Implementing Project Management
- Integration Management
- Lessons Learned
- Management
- Miscellaneous
- People Issues
- PMBOK
- PRINCE2
- Procurement Management
- Program Management
- Project Lifecycle Phases
- Project Management Advantages
- Project Management Advantages
- Project Management as a Career
- Project Management Best Practices
- Project Management Charts
- Project Management Definitions
- Project Management Ethics
- Project Management for Beginners
- Project Management Guides
- Project Management Musings
- Project Management Office
- Project Management Proposals
- Project Management Templates
- Project Portfolio Management
- Project Workforce Management
- Quality Management
- Requirements Management
- Risk Management
- Scheduling
- Scope Management
- SCRUM
- Soft Management
- Time Management
- Training
- Uncategorized
4 people have left comments
Years ago I had a project management instructor that often repeated “one hundred percent of nothing … is nothing.”
He drilled into us that percent completion meant nothing by itself. He taught the same approach of counting only completed tasks and that tasks had to be divided into fairly small duration efforts (two weeks was the largest he would accept).
This is always a good reminder, for doing anything in life.
Bruce
http://PMToolsThatWork.com
Reminds me of a case where one of the programmers, when reporting on the progress of his task made the following observation: “It’s done, but not done done.” Since then we’ve coined the phrase “it’s not done until it’s done done”.
One other point…
One of the ways to get over the creeping scheduling progress is to determine that prior to the commencement of work on the task the progress is 0%. Once work starts, progress is incremented to 50% and it only changes to 100% when the job is done. Obviously, from a project monitoring and controlling perspective, there’s still a need to determine progress, but this should be done based on the remaining effort to completion rather than % completion.
Shim
quantmleap.wordpress.com
See “The Confidence Question” at http://pm.blogs.com/ for another take on completion percents and estimating.
Laura