Project Estimation on Successful Projects

Project Estimation on Successful Projects

Project Estimation is one of the most important tasks for a successful project – and yet so many places get it wrong. If the estimation is wrong then you can be scuppered right from the start. You will be fighting an uphill battle all the way – and it will be unsuccessful.

I have never seen anything so unscientific as the process used for estimating IT projects. It goes something like this. If 100 metres can be run in 9.58 seconds then if you multiply that by 100 you can see how fast someone can run 10,000 metres.

What usually happens is very rough. The project estimator or estimators will take chunks and say this should take 10 days, this should take 15 days, this should take 12 days. This is just from their experience but it is a very rough and unscientific method of estimating.

Average Person

You often get a Project Manager coming in from the outside who estimates the projects. All they can estimate is how long it would take the average person in previous places he or she has worked on previous projects he or she has worked on.

They have no idea on the speed that the people at this new company can create software. Let’s face it, even the people who have been at the company a long time would be pretty poor at estimating how long people they know would take to do a piece of work never mind someone from the outside.

1oK Race

Tell me this. How long do you think it would take me to run 10,000 metres? That’s right, you know very little about me, what condition I am in, what age I am, whether I smoke or not etc. It could be anything. However, what if I gave you an extra piece of information?

What if I told you that the last time I ran 10,000 metres I did it in 40 minutes and that I had done some good training since and was now in slightly better condition.

That would help you a lot in estimating how fast I could run 10,000 metres next time out. If you then estimated that I could run it in 39 minutes next time you probably wouldn’t be very far out.

Available

So, now tell me. How often is this information available, i.e. how speedy are the analysts and developers in an organisation and what is the quality of the code that they produce? And yet, as you could see from my 10,000 meters question, this information is crucial if you are going to make a proper assessment and a proper estimate of how quickly a project can be done.

With the information of how fast I had done the 10,000 metres it would be entirely possible to give a reasonable estimate of how fast I could run a 10,000 metres again. Without this information you are likely to be wildly out in your estimation of how fast I could run the next 10,000 meters I participated in.

And yet this is how computer projects are normally estimated. Stupid isn’t it?

Company Speed

The first thing anyone should do before estimating a project is to find out how quickly that the company was able to do previous projects. This will not be as difficult as you may imagine. The company will have a record of how long the project took in terms of man days, how much the system cost and it will have the functionality of previous systems documented.

The first thing that a new Project Manager must do is to find out how fast the company was previously in creating a system. He or she should take a good example from a recent similarly sized project.

The best way to measure the speed of a company in doing projects is to count the function points. It’s not a perfect way of estimating a system but it’s a lot better than the usual finger-in-the air method that is currently used.

Function Points

You will have been provided with the number of Man Days that the previous system took to implement. Once you have your Function Points counted, you can then divide the Man Days by Function Points to see how many Function Points were previously delivered per day.

Once you have that information you can then use that to estimate the new project. You have the specification and so and count the expected Function Points. One problem that you have here is that as the system progresses the number of Function Points is likely to rise as functionality is added or reveals itself.

Original Spec

What you should do here is to ask for a copy of the original specification at the start of the previous project before any functionality was added. If you count the function points in that you can then see how much the number of Function Points increased through the project.

If it rose 30% through the project you would then add 30% to your estimate once you’ve counted the initial function Points as that is the growth you would expect. This may take a little time but it is well worthwhile.

Different Speeds

This shows you the rate that the organisation can create working code. However, the individuals on your project may not be all the same. Also, they may have different speeds of producing code. Although salaries are not that different in IT for people on the same grades at the same companies, productivity can be very different.

However, when estimating the length of time a project will take it is probably better to take the company average rather than factor in the different speeds that different developers and analysts go at. This will give you a little extra contingency.

Calculated

As we will explain later (in articles down this page), you will be able to get your better people to finish more quickly and therefore do a greater percentage of the work – but you shouldn’t take that for granted in the beginning. Otherwise you could be badly hit if some of the better people took ill or left the company.

So, now you have your scientifically calculated the speed that the organisation can create working code. You should use that now for your estimate of the project and include the Function Point growth contingency.

Accurate Project Tracking for Successful Projects

Accurate Project Tracking

One of the most important factors in a successful project is accurate Project Tracking. Projects are seldom tracked accurately for reasons we will describe below. Bad data means bad information provided to management who then take bad decisions based on that bad information.

Time Pressure

Virtually all the pressure put on those working on an IT Project is Time Pressure. To everyone involved in a project being on schedule is the most important aspect of the project while it is being built. That is because time is money and it is easily measurable.

From developer to project leader to Project Manager to the Project Sponsors and senior people in the company time against schedule is by far the most important measure of a project when it is being built.

Of course, when a system is implemented and put into production there are other factors that become more important, i.e. where the system does as it is supposed to do, whether or not it is easy to use, the quality of the system in terms of how it works and how often or little it falls over.

These will all become more important eventually than time. However, they are less easily measured than time and are less important in terms of the tracking of the system during the build.

Huge Mistake

Virtually all the Project Management tracking during a project is about tracking time. That is a huge mistake – and counterproductive. It is the main reason that projects are late and over budget.

Be careful what you measure because that is what you get. There is tremendous pressure on developers to deliver on time.

So they do. It takes the pressure off of them. However, sometimes they would be better to take a little longer to test the software to make sure that it is working properly before handing it over for testing.

However, at that stage, no one is putting quality or fit-for-purpose pressure on them.  So what you get is software on time – but not necessarily fit-for-purpose or properly tested.

Early is Cheap

It has been shown by studies that the earlier you catch a problem in the software development cycle the cheaper it is to fix. If it is caught early in the cycle it is very cheap to fix. If it is caught late, e.g. in User Acceptance testing or in Production it is very expensive to fix.

And yet there is so little pressure during the software development process to get things right from te start. It’s all time, time, time. That’s what gets measured and this where all the pressure comes from. And yet time is seldom the most critical factor on a project.

Solution

So, how do we get round this? How do we make the most important factors on a project the most important factors while the software is being built? How do we pit Fit-For-Purpose and Quality pressure on developers during a project?

That’s very easy. You ask the customers what is important to them, how important it is and then you reward all those along the software developer supply chain for giving the users what they want.

Simple, isn’t it?

How?

So how do you do that?

Very easy indeed!

You just ask the customers or users. You just ask them what they want from the Project and how important it is to them.

They usually come up with Fitness-for-Purpose(it does what they asked for and what they want), Quality (in terms of not falling over), Ease of Use, Timeliness and Documentation. You then ask them how important these different factors are. You ask them to give a relative weighting factor.

Results

It will usually go something like

5 – Fitness-for Purpose

3 – Quality

2 – Usability

2 – Timeliness

1 – Documentation

There you are. You see how relatively unimportant timeliness is in the scheme of things. And yet that is the main thing that is measured during a project. That is the source of the main pressure.

Counterproductive

However, this is counterproductive. The more time pressure you put on the less Quality, Usability and Fitness-for-Purpose you will get – and that will have a huge impact on timeliness in the end as all of this will have to be fixed late in the cycle rather than early when it would have been much cheaper to fix.

Once you know what the user wants from your software development and from the system you are going to deliver to them then you have got to make sure that this is what is delivered to them.

Supply Chain

So, how do you do that? You create a Supply Chain from developer to analyst to systems tester to User Acceptance tester to the End Customer. At each stage whoever is receiving the software will give it marks for Fitness-for-Purpose, Quality, Usabilty, Timeliness and Documentation. They will be marks out of ten.

These marks will then be multiplied by the weighting factors so that the Timeliness mark will multiplied by 2 and the Fitness-for-Purpose mark will be multiplied by 5. These marks will be added together to produce a total mark for the delivery.

Best Return on Investment

If I was allow to introduce just one process at any company I went into, it would be this one. This one makes the most difference. The reason is that it totally changes behaviour.

Whereas previously developers would succumb to the time pressures on them and hand over work they weren’t completely satisfied with, I found that the developers and analysts themselves would resist the time pressures a little more as the realised that the bigger marks were for Fitness-for-Purpose and Quality and wanted to make sure that they got good marks for those.

They would hold on to their software for an extra day or two beyond schedule to make sure they were completely satisfied with it and it wouldn’t keep bouncing back to them.

Right First Time

Getting things right first time makes a huge saving in timeliness as it saved in the usual heaps of rework that timeliness pressure usually means so, you see, the less time pressure you put on and the more quality pressure you put on the more time you save.

What I found when I implemented this was that projects and people needed a lot less managing. People know what is wanted and managed themselves. In fact even when you put time pressure on them they’ll resist you as they take the long term view and deliver what is most wanted and what gets them the highest marks.

The easiest way to run a project is to put in good processes that reward people for the right things. That’s what you are doing here. Yet, how few project do this.

What type of Project Managers do we want?

What type of Project Managers do we want?

Not all good programmers or good analysts become good Project Managers. It is in fact a very different skill from either of these.

How do we know who will become good Project Managers? One of the crucial skills needed is leadership. Leaders, in real life, tend to evolve rather than being appointed. How often do we see leaders of countries who have been appointed by their predecessor, being swept aside after the ‘great leader’ is gone.

Also there are some people who are used to succeeding in life and those who are used to failing. If one tennis player is used to losing to another player, then when losing again will take no great steps to reverse this.

When it comes to the time when the one who is used to winning is behind, he or she puts great mental and physical effort into reversing this situation. They just ‘can’t let it happen’, and it usually doesn’t.

Natural Leaders

Picking natural leaders who don’t let bad things happen, and who can right bad situations when they do happen, is crucial. This type of person usually has a positive attitude and is keen to insert the kind of processes into the software development lifecycle which will help him or her succeed. Also, on a project, when reverses happen, as they invariably will, they have the self will and belief to set it right.

Those who are not used to winning, as in life they are used to this situation, will spend their effort not in clearing up the mess but in justifying themselves and in making sure the blame does not attach itself to them. You need people who will grow in a crisis not shrink.

Selecting Project Managers – Category 4 Minks

Category 4 Minks – Selecting Project Managers

Selecting Project Managers is one of the most important things you can do. If you get it wrong the project is scuppered from the start. The right people with the best processes is the perfect mix. So what type of people do you want when selecting Project Managers?

Minks

A few years ago, in the UK, the Animal Liberation Movement, set free a number of minks from a mink farm. Some of the minks, who had been bred in captivity, remained in their cages even when the doors were opened. Others stayed out for a while but came back at feeding time. Others still stayed out but could not adapt to the wild and were either killed or died of starvation. Others however stayed, adapted to the wild and thrived in their new environment.

Try thinking of you employees and fellow workers and which categories that they would fit into. Select your Project Managers only from the ‘category 4 minks’. Do not confuse them with the ‘category 3 minks’ who are usually loose canons. Do not worry if they are relatively junior. Double or triple promote then if you have to.

Appreciate, also, that the ‘category 4 minks’ are the ones most likely to leave your organisation. Those are the ones that you most want to stay.

Promotion

If you promote the leader from within the ranks, you will find problems with those that they have leapfrogged on the way up. These problems come from people who want to stay at  the company but who assumed that, in the natural order of things, that their turn for promotion will come soon.

Many of these people are good analysts or programmers that you would wish to keep at the company. You need to be able to manage this or you’ll be left with good leaders but fewer good technical workers and especially fewer people with good knowledge of your systems.

Different Strokes

How do you handle this? By having different ways of progressing up the company. Very often people mainly want promotions because of the extra status and income attached to it. You must find other ways of giving them this status and income if they achieve good results.