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.
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.
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.
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?
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.
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.
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.
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.