-
Know Your Audience When Developing the Project Management Plan
October 11, 2008
-
Project Executing Process - Kick-off Meeting
October 10, 2008
-
No Creation of Best Practices - Project Management Mistake # 15
October 10, 2008
-
Cutting Project Costs and Exceeding Expectations – A Simple Seven Step Solution
October 10, 2008
-
Tips For Passing the PMP Certification Exam
October 10, 2008
-
Procurement Management in Project Management - Source Selection
October 9, 2008
-
The Holy Grail of Project Management Process and Methodology
October 9, 2008
-
Reviews in Project Management are Required
October 9, 2008
-
The Phased Approach to Project Management Implementation
October 9, 2008
-
Specific Responsibilities of the Project Manager
October 9, 2008
Done or not Done: That is the Question
March 31, 2008 | Author: admin | Filed under: Time Management, Activity Duration Estimate, Project Management Best Practices
Done or not Done: That is the Question
By Michael Schobert
“How far are you with this task?”. This question is quickly asked and chances that you get an answer like “we are 80% done” are very high.
Does such an answer really makes sense? How do humans assess the progress of a task? According to the Pareto principle we might need 80% of the effort to fulfill the last 20% of the task, but most likely we perceive this differently (more linear). So even if we have the best intentions, the human brain is being tricked here.
So what are the options?
There are a couple of ways to report the completion of a task:
- Binary (0-100): Either a task is finished or considered as not yet started
- Binary (50-100): As soon as a task has been started, it is considered as 50% done
- Linear: If a task is scheduled to take 10 days and 8 have been spend on that task it is 80% done. This is the Microsoft Project way
- Subjective: Most often used in ad hoc reporting. The team is asked and tells their gut feeling (more or less)
The advantage of the binary strategies is that you are not tricked by the nonlinearity of things. There is no false security of having plenty of time.
And there is another positive effect: Designing tasks to be suitable for binary evaluation. By the team being aware that a task is either done or not, they will most likely start to design tasks that are actually suited for this approach: Not too big but still one entity. However it is very critical to resist the tendency of making tasks too small (to get them done quickly). Unfortunately there is no rule of thumb of how long a “standard” task should be (do not trust anybody who states otherwise).
There is another very important aspect to this: Defining the task in general and the criteria of completion in particular is key. As said above, a task needs to be a kind of atomic effort. You should not confuse this with an artifact or deliverable. A task can be a part of an unfinished deliverable but needs to have clear completion criteria.
Binary reporting also prevents micro management. The team will report the task done, when it is done. Asking beforehand does not make much sense as the binary answer is not done yet (either 0% or 50%). Having said this, it is the responsibility of the person or team that owns the task to escalate in time when they see a risk of not being able to complete the task in time.
Whatever you do, always remember to keep a buffer in project planning.
Michael Schobert is currently working for Reuters in Frankfurt, Germany as Head of the Solution Services Group. He joint the IT and finance industry 10 years ago. He has worked for companies like Siemens, Sun Microsystems and abaXX in various roles as Software Engineer, Architect, Project Manager and Manager. During these years he was responsible for many projects and acquired a broad experience in this space. He is a strong believer in the agile style of live and work.
Michael has studied Mechanical Engineering, Physics and Computer Science and is member of the ACM and IEEE (Computer Society).
Michael runs a professional blog: This And That.
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=""> <code> <em> <i> <strike> <strong>
All fields marked with " * " are required.
- Agile Project Management
- 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 Management Advantages
- Project Management Best Practices
- Project Management Charts
- Project Management Definitions
- Project Management Ethics
- Project Management for Beginners
- 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
1 person has left a comment
Occasionally I’ll get an email from a user who wants to mark tasks some percent done, which LiquidPlanner doesn’t do. The Pareto principle demonstrates why that approach will likely mislead project schedulers, whatever their role. Thanks for the reference!