Perfect IT Project
What is your perfect IT project?
There are two ways of looking at this. You could look upon the perfect project as one where you got lots of money for doing very little work, but we will concentrate here on what would make a project successful and enjoyable to work on.
All Requirements Gathered for Perfect IT Project
When I worked at American Express, in looking for a new methodology that would fit their purposes, I went round asking the IT department managers what they wanted from a new methodology.
They replied that the biggest problem that they had was in getting the requirements phase right. There were a number of reasons for that.
The prefect IT project would have buy-in from senior management. The correct business users would be provided. Moreover, if they cancelled a requirements gathering meeting, especially if they were just one of several crucial people attending the meeting, then they would have to answer to the senior management project sponsor.
You could put together a list of all the right people between the project and the project sponsor. This would be with the help of area management.
Experienced business analysts could then use good techniques like Use Cases or Event Modelling to gather all the requirements.
The project sponsor would then make sure that there were no delays to the business users signing off on the project. This can cause massive delays and large costs against the project.
A project need not remain static in terms of requirements. The business doesn‘t remain static. Changes going into the current system to enhance the business, need to go into the new system too.
However, they should understand from the start that they should keep these to a minimum. Also, there will be consequences in terms of budget and time if the project incorporates any new changes.
On the perfect project, you would allocate time in the beginning for the incorporation of a certain amount of business changes in the requirements. This time would be separate from contingency time.
Most projects are dead in the water before they start due to poor estimating. What normally happens is that the estimators say ‘that will take 7 days and that will take five’. It is totally unscientific.
The total estimate, which does not take enough account of time needed for management and co-ordination, is then further reduced after pressure put on by suspicious management who want to meet certain budget and time deadlines.
On the perfect project, the estimators would know the productivity of the company on previous projects, and the individuals on it.
They would know the productivity they can expect when using the languages and tools on the project. They would use a scientific measure like Function Point Analysis to determine the amount of functionality on the project.
Also, they would also know by how much functionality had increased in previous projects from the initial estimate to the final implemented system.
They would use this information to create an estimate for the project and the individual parts of the project that they can meet.
Normally projects go horribly wrong here. Project management seldom know the real status of the project. It is too easy for people on the project to hide, at least in the initial stages of the project, the fact that they are behind.
When they get behind on one task, they say on their weekly time sheet that they are more advanced than they actually are. When they find that difficult to hide, they start allocating time to tasks they have hardly started.
The project manager comes around each week to track progress but the project members give him or her duff data. He or she passes on duff information on project progress to senior management who think everything is going well. It always does in the first few months of a project.
Why they never learn, I don‘t know. Because they are making the same mistake on project after project on companies up and down the land.
Details of the Perfect IT Project
A good project would micro manage tasks, with those tasks split into smaller tasks of bite size proportions. There should be no 85% complete. No time should be considered to have been spent on a task till the whole task is completed. This should be easily provable.
The perfect project, however, would track completely differently. Time deadlines are too threatening and are bad for project morale especially when the deadlines are too tight. You can use some psychology here.
On the perfect project, you should set no time deadlines at all. Although, of course there would be a project plan known only to management.
Instead, developers should be told that a particular piece of work contained, for example, 20 Function Points, and the developers normal delivery rate was 20 function Points a month.
In this way, each piece of work handed out to a developer would be a challenge to them to better themselves.They could outdo what they‘ve done in the past. It would not be seen as a threat.
It has been proved in the past that developers are measurably more productive when there is no estimate for a piece of work at all. Indeed as soon as a time is allocated for a piece of work, that becomes the minimum time. It is no longer an estimate.
We will return to this theme again.
What would be your perfect IT project?
Ad – Contractor Services
If you do need an umbrella company you could try one of the following:-
Or would you prefer to get expert advice about which umbrella company is right for your specific needs? If so fill in the form below and they will be in touch.
For Mortgages specially designed for contractors try Specialist Contractor Mortgages.
If you know anyone else who would find this article useful, please share it with them using the social media buttons at the top and bottom of the page.