EDV Software Solutions Ltd

Project Management is an important topic in IT. There are many books, articles, courses, certificates, software tools and what not on or for Project Management. There are many experts, as well as "experts", on the IT job market. So why do so many IT projects fail, miss their deadlines, bust their budget or fail to meet expectations?

 

Having taken part on many an IT project we have learned that many businesses simply go through the motions rather than genuinely manage. The issues in IT project management are about leadership and controlling, communication, documentation, competence and expertise.

 

Typically at the beginning of a software development project its goal should be specified. The requirements should be gathered and analysed and made into a specification. A written document should be prepared. Never mind what we call it or what it is:  technical specification or design or whatever. This, in other industries, is a matter of course. When building a house you have drawings and other documentation for the planning permission. When making a movie you have the book or script or screenplay. Yes there have been movies filmed without a script or houses built without planning. But these are exceptions to the rule. In the IT world we have seen many projects with insufficient or no planning, specification, design, project manual. Sometimes (actually often) they do not stick to it even if the specification is there. 

 

A lot must be clarified before any software development can get going. You have made your bed of issues if you do not properly plan resources. You need a budget fitting the task. Instead the task is often required to fit the budget. Remember, in the IT you cannot plan as precisely as in other industries. The rule of thumb is to double the budget calculation to allow for contingencies. 

 

Before the project gets going and often even after its start the human resources need to be organized. You will have to build the project team using in-house staff and/or by hiring contractors. Or you may have to subcontract other companies for certain project parts. The employees (staff members) have on the one hand their place in the company's structure and they have their line manager; on the other hand they get assigned to project teams the leader of which is their project manager (who usually is not their line manager). Now human resources, recruiters, employment agencies and businesses usually lack the understanding of the IT job descriptions and qualifications. It is essential that the project manager is (not only) for the recruitment seconded by a person with the required understanding. Do not allow your HR or other recruiters to filter out CV's of highly skilled IT-experts while the recruiters do not understand the value of those for the project. Recruiters usually look for certain keywords in the CV. If one of the requirements is say 'BS2000 or z/OS' than candidates with 'various mainframe operating systems' experience will be filtered out even though they deserve to be considered. It is like recruiting a Peugeot driver and not accepting one who merely states having driven most cars on the market. The recruiter would like to see the word 'Peugeot' in the CV. This sounds ridiculous but: everybody, including recruiters, knows that Peugeot is a car. They often do not know that BS2000 and z/OS are mainframe operating systems. 

 

The project team must be well structured. Your project manager will structure the team based on task, available resources, project size, etc. In a software development project of a considerable size you will have separate (sub-)teams for specification and design, software development (includes coding, simple functional tests), quality assurance (includes test development, test tool development, testing), system/customer service (including documentation, packaging, roll out, user support, etc.).  You will need a project office to store, keep, make available for changes (, etc.) programs, procedures, scripts, documents, etc.  The project office can thus be and is sometimes called program office in software development projects. User support would usually be organised in three levels. The customer service is the 1st line of support, quality assurance the 2nd line of support,  software development the 3rd line of support.

 

The software development process is very rarely a one-off affair. Most software systems need regular updates and new versions. E.g. a system for processing of tax would need annual changes following changes in taxation. This should really be treated as one ongoing project with distinct versions as opposed to having a new project every year. The advantage is obvious. We do not set up a new project team every year, we keep the know-how and build up and on the previous experience. In the usual situation the design team would be working on version n (e.g. 11), the development team on version n-1 (e.g. 10), the quality assurance on version n-2 (e.g. 9), whilst the system service would distribute and support version n-3 (e.g. 8). All the teams deal with issues of previous (still supported) versions while working on their current versions.  

 

All teams have well defined milestones and deadlines. Use your own system if you have one in place that you are happy with. Otherwise you might want to describe your milestones as xxxnn, whereby xxx is DES for design, DEV for development, QAS for quality assurance and CUS for customer system service. nn is a number between 01 and 99. You would 'declare' a milestone as and when it is 'reached'. Let us discuss QAS milestones as an example. You would declare QAS05 when the developers have made their product available for testing by the quality assurance team (this would correspond to the developers milestone of DEV85). The QA team would 'quick-test' the product and 'accept' it by declaring QAS10. Having succesfully run complex functional tests would trigger QAS20. Further milestones would cover the successful completion of other tests. When the product has been fully and successfully tested it will be made available to system service. This would be QAS85 and CUS05 at the same time. When issues arise the product is handed back to the developers and the milestones will be run through again. This is why we describe the method as SDLC (Software Development LIfe Cycle). CUS95 would mean the end of the product life.  

Acknowledgment: This is based on our experience at Siemens. 

 

A  proper system with regard to versions, milestones, deadlines and resources makes realistic reporting possible. The work progress in many IT projects is often reported using quantities without meaning. E.g. The computer system is 65% done. 65% of what? Why 65 and not 52 or 73? Is it 65% of available time? Is it 65% of planned person-hours? Is it 65% of planned lines of code? Or is it lines of code written? Or written and tested? May be the 65% of code written are the easier lines of code and we shall need for the remaining 45% four times more human resources, budget and what not.  

 

An unwanted consequence of not having proper command over work progress is that in many IT projects we have two parallel worlds with regard to flow of information, reporting and controlling. The software developers and other personnell at the base try in their real world to do their job as well as they can while the top management work with written and oral communiques describing an ideal world with meaningless data on work progress. The divide between the two worlds is at the lowest level of management where the world down in the management hierarchy is a different one from the the world of the upper management levels right to the top.  

 

There is an abundance of computer based systems to support project management. It is not so important what you use. Important is how you use it. It should not be used just for complying with red tape requirements. It should be used for planning and controlling the project. 

 

For large projects we will have to divide the project into subprojects and we will have to accordingly subdivide  the teams. In the above example of a tax project we may need separate teams for the various taxes (income tax, VAT, corporate tax, etc.) and a data base team, systems team, etc. We would then use various tools to manage the complexity (e.g. critical path method).   

 

It should be noted that the product of software development is not only the system of programs, procedures, scripts, etc. The documentation is an inherent part of the product. 

The documentation starts as written specification/design. This gets handed over to software development and they turn it into the software development documentation which they hand over to quality assurance with the programs, etc. They in their turn hand over to customer system service the quality assurance documentation based on the software development documentation and programs, etc. Customer service hands over to the user/customer the user documentation and programs, etc. (User documentation has usually two parts - one on running the system and one on using it).

 

The above description of handing over (making available) and receiving and accepting the product is to be handled by and through the program office. No other team and no customer/user has direct access to the program office libraries or data bases. No one outside the program office has the write privilege for the program office libraries and data bases. The documents, programs, etc would be made available to those and those only who need them. The documents, programs, etc to be stored in the program office libraries or data bases would get copied into them by the program office from where these have been made available. The program office libraries and data bases store everything with regard to versions. It must be always possible to go back to a previous version, if need be.  We may want to say 'to post' or 'to send' instead of 'to  hand over'. We may use  'to receive' when an object has been handed over but it has not been 'accepted' yet.

 

The decision on what the hardware (HW) and software (SW) environment is going to be is an important part of the planning process. The rule of thumb is: do not change the existing HW/SW environment unless you have to and you really really know why you should change it. We can often observe dumping mainframes or certain computer languages like COBOL because it is fashionable to have a network of PC's running Windows with some "new" or "up-to-date" language.  You probably do need mainframes in a project with very large and complex and sensitive data where thousands of users need simultaneous access whereby performance and safety and security are particularly important. And you will have your PC's anyway as nowadays big systems come in the form of multi-tier systems, or networks, with mainframes, UNIX computers and PC's (PC as user interface).