developA few weeks ago, I asked one of our Project Managers for a Development Worksheet and saw a list of tasks with completion percentages at a task level.  I was very surprised since, at Information Concepts, we do not use a percentage completion methodology at the development task level!

In my 30-plus years at Information Concepts, I have managed or overseen the management of well over 100 software development projects of all sizes, so I have seen the pitfalls here.  I put together this post to better explain how we should be managing development projects, and why.

When we start a development project, we ask the Project Manager on our Business team to create a Development Worksheet.  A Development Worksheet is simply a spreadsheet containing a list of all development tasks required to complete the project, organized logically by system component (Web Pages, Business Functions, Web Services, etc. organized by Subsystem).  We do this in a spreadsheet instead of a project plan (which we use for planning purposes) because it reduces the noise typically contained on a project plan, eliminates any distractions, and provides a very clear picture of the actual project status.

As the project moves forward, the Lead Analyst will update the status of each task with the person performing the task, the date it was started, its status, and its eventual completion date.  We only recognize 3 valid statuses:

  • Not Started.
  • Started.
  • Complete.

At Information Concepts, we do not use percentage completion at the development task level.

Why not?  Very simply because there is no way to accurately project the percent of completion for a development task prior to its actual completion.  Additionally, percentage completion provides a misleading indicator of progress.  I have seen many projects with multiple tasks marked as 80% or 90% complete, however, these tasks cannot be finished because of an issue blocking their completion — which might require a change to requirements or a development prerequisite that cannot be completed and will, therefore, need to be redefined.  More often than not, this gets overlooked because of the 90% completion indicator.

Instead, when we create development tasks, we need to make sure they are easy to understand, manage, and track.  Tasks are at a very granular level.  Rules for defining tasks are as follows:

  • A Task should be comprised of one (and only one) logical unit of work (i.e. a Page or Screen, a complex Grid or Table, a Report, a business function, etc.).
  • Make sure that each Task can be independently tested.  Ideally, it should be possible to test a Task stand-alone (although this may not always be possible).
  • Keep tasks small and short.  A task should be no more than 2-3 days in length. This allows fast identification of any problem tasks.  If a Task is longer than a few days, divide it into multiple subtasks.

A Task is not complete until it has been thoroughly tested.  Complete means complete!  It does not mean almost complete, or 90% complete, or complete if one last item is finished in some other place in the development process.

The only time it is acceptable to use a percentage completion methodology is for a large Task (i.e. subsystems or major application components) with multiple smaller tasks or subtasks.   For example, in a subsystem with 5 screens, if 2 of these 5 screens have been completed, the high level task can be considered 40% complete.  Although this is misleading since the size of any given subtask can be radically different, it is necessary for project reporting purposes.

If we use the methodology described above, it will greatly simplify identification of problems during development – which is the actual goal of project tracking!

Cary Toor (2 Posts)

Cary Toor is a Co-Founder and Principal of Information Concepts, Inc. Since the company’s founding in 1982, he has personally managed or overseen the management of numerous large and small software development projects for Information Concepts’ customers, as well as provided software architecture support for complex projects. In this role, he developed Information Concepts Project Management Strategy, including processes and techniques, which have allowed Information Concepts to have an unparalleled success rate in delivery of software development projects to its customers.


Cary Toor (2 Posts)

Cary Toor is a Co-Founder and Principal of Information Concepts, Inc. Since the company’s founding in 1982, he has personally managed or overseen the management of numerous large and small software development projects for Information Concepts’ customers, as well as provided software architecture support for complex projects. In this role, he developed Information Concepts Project Management Strategy, including processes and techniques, which have allowed Information Concepts to have an unparalleled success rate in delivery of software development projects to its customers.