The Five Key Elements of Project Management
For this project the five key elements are:
1. An early appreciation of the scope of the project.
Too many people think that the Y2K problem is just a technical issue. It is not. It is as much a business issue as anything. In tandem with the team examining the actual systems, end users of those systems must be prepared to:
This project is going to require a mix of ‘helicopter perspectives’ and ‘magnifying glass detail’ from wide spectrum of the team. It is more than fixing the Y2K problem; it is examining how CHH does its business.
2. Shortest possible critical path with maximum ability to parallel threads.
The deadline for this project is coming, on time, ready or not. It is not acceptable to have delays that push out the finish date too far. Should a particular step be taking too long, it must have a minimal impact on other stages. Also, it should be constructed in such a way that extra resources can be thrown at it [cf. 4.]. The classical SDLC approach will not be sufficient, as it is not designed to cope with a massively parallel development. The iterative approach adopted by DSS, RAD & ASD will be more suited at times. ASD in particular is well suited to chaotic situations, which Y2K is bound to be.
A corollary of this is that "big bang" file conversions are out. They must be done "by osmosis" [cf. "bilingual" programs].
3. Make sure that (almost) everyone knows (almost) everything that’s happening.
Time and again I have seen projects founder because of lack of information flow up, down or sideways. This does not mean large formal meetings where each manager takes turns at telling the others what they’re doing. It’s more informal via community white boards and chats over the partitions. It requires people who are open minded and willing to share their (work) problems, offer advice to others, and willing to accept (or at least consider) advice given.
Ideas and decisions must be contestable. Too often I have seen arbitrary decisions made by people without the knowledge to see better ways. Alternatives are then turned down with "Sorry, it’s already been decided." This kills innovation and lateral thinking solutions quicker than almost anything else [cf. 5.]
4. Having experienced multi-disciplined people with the right attitude and aptitude available to rapidly provide expertise at crisis points.
Having rigid departmental boundaries or rigid adherence to job specifications doesn’t help anyone when the boat starts sinking. It’s all hands to the pumps. No matter how well planned this project may be, there will be times when the unexpected happens. It may require reallocation of resources in order to help it through. Just because some has a title of Cobol Programmer doesn’t mean that they don’t know how to operate a computer or understand timber milling.
In summary, the teams that are set up must be flexible and willing to provide any service where it’s needed.
5. Realise that a project has to have quality designed into it rather than have defects tested out of it.
Normally I would recommend an inspection system such as proposed by Michael Fagan of IBM. However, inspection works best when the final outcome is well defined, and there is some debate about whether Y2K work is well defined! Whilst the inherently unknown nature of work to be done is there, it can be argued that the outcome is well known. It is not so much establishing the exact work to be done as assembling a toolbox that will handle each situation as it arises.
Thus, whilst the details may not be pre-inspected in the usual sense, the processes can be, and indeed should. This can be done in several stages: a quick reconnaissance, details of approaches that could be taken, then inspection, then a decision on the most appropriate option. Once these details are fleshed out, then another inspection can take place.
Certainly the testing strategy can be pre-inspected, remembering that the purpose of testing should be to prove the implementation of a concept rather than check for design defects.