Project Smart ~ Exploring trends and developments in project management today

Calendar iconNot recorded
Adobe PDF icon

Estimating by Percentages

~ By Tim Bryce

Red blocks with the percent sign on a white background

Remember, it's Ready, Aim, Fire; any other sequence is counterproductive.

Bryce's Law

Having been involved with the systems methodologies field for over 30 years I have been occasionally asked what percentage of time in a project should typically be devoted to a specific phase of work, for example a Phase 1 Feasibility Study, Phase 2 Systems Design, etc. Basically, the reason the person wants to know this is to use it as a means for estimating the remainder of the project. For example, if I were to say Phase 1 represents 10% of the overall project, they would simply multiply the amount of time spent in Phase 1 by ten. This is an unreliable approach for estimating, which is why I usually balk at giving out such figures.

Systems development projects vary in size from large to small and although statistics should certainly be maintained, I still consider this an erroneous approach to estimating. Instead, I recommend basing an estimate on a rough design of the product to be built (the system), including all of its pieces and parts, such as inputs, outputs, files, records, data elements, etc. Some of these components may be reused from other systems, some may require modification, and some may be entirely new. This is called estimating based on the system's "Bill of Materials," a simple concept derived from engineering and manufacturing. Even if a project only involves a single program (as opposed to a major system), I would still examine the types and number of components affected by the assignment.

Having said all of this, let me give you my spin on the proportion of work in the typical systems development project. I have seen many companies skip through the early phases in order to get to the programming phases, which is considered the important work. Under this scenario, programming represents 85% of the project. Instead I advocate more time spent in the early phases for better clarity of requirements definition and for producing better specifications for the programmers and DBAs to follow. Under this scenario, I see as much as 60% in the early phases involving systems analysis and design, 15% in programming, and 25% in implementation and review. You heard right, 15% in programming. Why the disparity? Simply because programmers have long suffered from the lack of decent specifications and end up spinning their wheels over and over again trying to deliver what is needed. But if you concentrate on better specifications upfront, the guesswork is eliminated for the programmer.

Some people consider the upfront work to be somewhat frivolous, that the "real work" is down in programming. I don't know why this is, perhaps programming is more tangible since screens and reports can be visibly shown to people. But I do not subscribe to this notion, and believe the vital work to be in the early phases, but then again, I am considered a dinosaur by the "Agile" methodology people. Regardless, if you have to build anything of substance, be it a bridge, a skyscraper, an automobile, or a system or a single program, you have to do your homework first, otherwise you find yourself constantly tearing things down and rebuilding them over and over again. If we built bridges the same way we build systems in this country, this would be a nation run by ferryboats.

One last word on applying percentages to project estimates, the danger here is that you might calculate you are 90% complete; inevitably you will discover the last 10% will take forever. So, my recommendation is to avoid the percentage trap and consider the Bill of Materials you are going to work on instead.


Tim Bryce is the Managing Director of M. Bryce & Associates (MBA) of Palm Harbour, Florida, a management consulting firm specialising in Information Resource Management (IRM). Mr. Bryce has over 30 years of experience in the field. He is available for training and consulting on an international basis. His corporate web page is at: http://www.phmainstreet.com/mba/


Comments

Be the first to comment on this article.

Add a comment



(never displayed)



 
2000
Which is darker: black or white?
Notify me of new comments via email.
Remember my form inputs on this computer.

Seven Key Principles of Project Management

Hand holding a key with success written on the fob

If you're looking for guidance to help you manage your project with added confidence, then this article will help you.

Project Plans: 10 Essential Elements

Four colourful tags spelling the word plan

A project plan is more than just a Gantt chart, but do you know what you must have in your plan? This article takes you through the ten essential elements.

Resolving Project Team Conflicts

Two women having an argument in an office

Conflicts on project teams are a fact of life! Only on rare occasions do conflicts not arise. As project manager you must manage these conflicts.

A Brief History of SMART Goals

Set your goals written on blue paper

In this history of SMART goals, I look at where the acronym came from, who developed it, what the critics say and why it has become popular.

PROJECT SMART is the project management resource that helps managers at all levels improve their performance. We provide an important knowledge base for those involved in managing projects of all kinds. With weekly exclusive updates, we keep you in touch with the latest project management thinking.

WE ARE CONNECTED ~ Follow us on social media to get regular updates and opinion on what's happening in the world of project management.


Latest Comments

Joseph Marandus commented on…
How to Apply PRINCE2: Engaging Senior Management in Your Projects
- Tue 21 March 1:59pm

Janine Greene commented on…
The Role of the Project Manager
- Fri 17 March 1:30pm

Ben commented on…
The Role of the Project Manager
- Sun 12 March 12:30pm

Latest tweets

General Project Management • No Sponsor https://t.co/ii52CgAiCs #projectsmart #pmot about 8 days ago

General Project Management • Re: Software Product Delivery Plan for an Agile project https://t.co/v8ondVdaME #projectsmart #pmot about 9 days ago

General Project Management • Re: How do you track who from your human resources have related… https://t.co/QzAyOJ27cp #projectsmart #pmot about 10 days ago