APPLICATION TO SOFTWARE ENGINEERING

As soon as a project gives any sign at all of starting, we are in a position to make a list of jobs for it. As we have already discussed, the list should be detailed to the first milestone and give the major milestones thereafter. In addition, what you can do is to add any other available detail to the remaining milestones. This isn't essential, but given that we may have such detail available, and that we will have to put it in some day, we may as well do it now. The advantage of this is that it starts to give us some feel for the magnitude of the remainder of the project. (We will return to this idea in Appendix 1.)

In the two sections that follow I have given real-life examples of job lists. The project for Telecom Ireland Software (TIS) has four major jobs within it (remember our recursive definition of project):

• Decide to implement ISO 9001

• Set up organization

• Set up and install quality system

• Apply for certification

The first job has been further broken down into four jobs, and these have been estimated at a total of five man-days. The remainder of the job list then gives as much as is known about the rest of the project. Note that I have gone down, wherever possible, to very low levels of detail. This will be the basis of our estimating method in Appendix 1.

EXAMPLE 1: PRELIMINARY PLAN TO GET ISO 9001 CERTIFICATION

This example is a project to achieve the ISO 9001 quality standard accreditation (Rothery, 1991).

1. Decide to implement ISO 9001

Develop a quality policy statement and have this approved by the board of TIS and explained to everyone in ACME Software. Total 20 man-days estimated. Includes:

• Develop statement

• Review internally

• Take to board for approval

• Circulate to everybody

• Education, i.e. Standards Bodies ( videos or other support available?), give an introductory course, ongoing quality training, ongoing awareness of quality program, issues and results

2. Set up organization

• Nominate a quality manager

• Set up a quality improvement team

3. Set up and install quality system

This involves installing and running a quality system which is described by a quality manual. There are two sides to the work: write the quality manual describing the quality system ("document what you do") and install and run the system described in the quality manual ("do what you document").

These two aspects of the work would typically proceed in parallel. A framework for a quality manual has already been drawn up. The bulk of the work involved in achieving ISO 9001 is to devise the quality system, implement it and document it within the quality manual framework.

The bulk of the rest of this document estimates the size of that task, both in terms of setting up/installing the procedure and documenting it in the quality manual. Some notes on implementing the quality system:

• it would be useful to review the contents of the quality manual with the Standards Bodies or a quality auditor /consultant;

• plan should allow for up to ten man-days of consultant's time;

• integral elements in implementing the quality system are

  • the measurement of the quality of products and the processes which produce them

  • calculating the cost of quality

  • taking corrective action based on the measurements above.

Note

In the following example all estimates are in man-days.

SECTION IN QUALITY MANUAL			SETUP/INSTALL PROCEDURE	DOCUMENT PROCEDURE
1	Introduction
	1.1	Company description extract from marketing brochures		0.5
	1.2	Place of quality manual in overall procedures - written
	1.3	Quality policy statement (get from 1 above) and education program	20	1
	1.4	Use TIS Organization chart
	1.5	Define an amendment procedure	0.5	0.5
	1.6	Circulation list and procedure	0.5
	Totals		21	2
2	Documentation
	2.1	Use Myles' document	0.5	0.5
	2.2	Use Myles' document	0.5	0.5
	2.3	Document management (2 documents)
		- Write	5
		- Review	1
		- Update	2
		- Approve	1
		- Publish	1	1
	Totals		11	2
3	Project management
	3.1	Project management methodology (adopt? Document w.r.t book. Project exit criteria, sample project plan)	1	4
	3.2	Estimating & scheduling (document w.r.t book & MS Project. Include examples; historical database)	1	4
	3.3	Monitoring & reporting (needs an EV system; project status report; sample progress report)	5	6
		Include timesheets and time recording	1	1
	Totals		8	15
4	Project Life Cycle
	4.1	Overview		1
	4.2	Requirements spec.
		- Research		1
		- Write (including template)		2
		- Review (possibly by using)	-
		- Rework		1
		- Release	0.5
	4.3	High-level design
		- Research		1
		- Write (inc. deliverables, review/exit criteria, template)		2
		- Review ( ideally by using)	-
		- Rework		1
		- Release	0.5
	4.4	Low-level design (inc. user documentation and test plans)
		- Research		2
		- Write (inc. template)		3
		- Review (ideally by using)	-
		- Rework		1
		- Release	0.5
	4.5	Implementation (inc. code, unit test, integration and test)
		- Research (inc. unit development folder (UDFs), walkthroughs, etc.)		2
		- Write (inc. deliverables, review/exit criteria, template)		3
		- Review (ideally by using)	-
		- Rework		1
		- Release	0.5
	4.6	Alpha test
		- Research		2
		- Write (inc. deliverables, review/exit criteria, template)		3
		- Review (ideally by using)	-
		- Rework		1
		- Release	0.5
	4.7	Beta test
		- Research		2
		- Write (inc. deliverables, review/exit criteria, template)		3
		- Review (ideally by using)	-
		- Rework		1
		- Release	0.5
	4.8	Operation and maintenance
		- Research		2
		- Write (inc. deliverables, review/exit criteria, template)		3
		- Review (ideally by using)	-
		- Rework		1
		- Release	0.5
	4.9	Configuration management and change control
		- Research		3
		- Write (inc. deliverables, review/exit criteria, template)		5
		- Review (ideally by using)	-
		- Rework		1
		- Release	0.5
	Totals		4	48
5	Invoicing and accounting
	Guess		3	5
6	Training
	Will refer to TIS training plan (to be estimated separately)		1	1
7	Subcontractors
	Guess		1	10
8	Orders and enquiries
	Not required by ISO 9001 but a good thing to include. Includes prospects list.		3	5
	Guess
9	Personnel
	9.1	General procedures	5	5
	9.2	Organization chart - done
	9.3	Grading structure/Job descriptions	10	20
	9.4	Salary scales	10	10
	Totals		25	35
10	The quality system Itself
	10.1	Internal audits - review/update of procedures (quality)	5	5
	10.2	Cost of quality - maintenance of quality records (guess)	5	5
	Totals		10	10

4. Apply for certification

Sequence of events is:

Run an internal audit (or perhaps a series of them)	20
Submit application form and a copy of the quality manual (QM)	2
Standards Bodies vet QM and notify TIS of any discrepancies which must then be rectified	20
When these are rectified, Standards Bodies audit TIS onsite and again identify discrepancies	30
Standards Bodies verify remedial action has been taken and recommend award of ISO 9001 certificate	10
Total	82

EXAMPLE 2: PLAN FOR A SOFTWARE ENGINEERING PROJECT

The second example is for a software engineering project as shown in Figure 2.2. This job list was done using MS Project.

Figure 2.2. Example of project plan

Don't spend too much time going into these figures in any detail (for one thing, they're not complete, so don't assume that, for example, you'll get ISO 9001 accreditation by following them!). They are merely snapshots of projects at a particular point in time. They are given here to illustrate the following important points in connection with making job lists.

• Use a project planning tool, such as MS Project, if at all possible “ they give so much more clarity as I think is illustrated by the difference between the plans in Example 1 and Example 2. The effort involved in learning and inputting information to them will be repaid a hundredfold in the understanding, flexibility, responsiveness and breadth of vision that this computer model of your project will give you. As I become older and more set in my ways, I venture to suggest that anyone who doesn't use one of these things is nuts!

• Write down the major milestones.

• Fill out the first milestone in complete detail.

• Fill out the remaining milestones with as much detail as is available (you can use the checklist given previously to assist you in doing this).

And what level of detail are we talking about? This is one that always seems to cause people problems. Well, note that the example has 500 man-days in it. The job list contains 237 jobs. This means that on average each job covers between two and three man-days. More generally , I think somewhere between one and five man-days is an acceptable level of detail to aim for. A pain in the neck? You bet. But this is the only way that success can be assured “ by ensuring that no matter how big the project is, that each component is planned and tracked by someone at the day level of detail. It doesn't have to be you, and on a big project it won't be “ but someone needs to do it.

I know the following to be absolutely true: when you break it right down, any project ends up as a large number of occurrences of Joe Soap or Jill Bloggs spending two days here, or half a day there doing Job A prior to Job B. Now, as the project manager, there are two crucial issues that you have to address. These are: (1) are we consciously going to decide who will work on what when? and (2) if so, when are we going to decide?

The first is not as dumb as it sounds. All project managers hand out work assignments which are more or less detailed. There is, then, an inherent assumption that these assignments will get translated into the two days here/half day there we talked about earlier. If they do, fine. But if they don't then it means that some force other than the project manager “ let's call it Life “ is making these work allocations. The allocations will get done, have no fear about that, because if you don't do them, Life will. But one of the things about Life is that it can be unfair, and if you rely on Life to do your work allocations for you, then you're asking for trouble.

Let's look at the second issue. Assuming you're consciously going to allocate your people to jobs, when should you do this? Well, you have a choice. You can either do it at the beginning, during the planning part of a project when things are relatively quiet, or you can do it in the middle of the project, in the heat of battle, when the bombs are falling and all hell is breaking loose. You will have to do it, so why not make things easy on yourself, and do as much as you can at the beginning when the pressures aren't so bad? And don't worry about it not getting done because, as before, Life will intervene and do it for you. But again, you need that kind of assistance like you need a hole in the head.

Let's try to summarize what we're saying here about levels of detail. There is a quote in probably the most famous book on software project management, The Mythical Man-Month (Brooks, 1975): " How does a project get to be a year late? " The answer? " one day at a time . "

Know where your man-days are going, every one of them. Spend them wisely. If you don't, you'll find out just how fickle Life can be.

Once, at a seminar, I was pushing the idea of the plan being at the day level of detail, and somebody asked whether this didn't present an unacceptable overhead. Specifically, the question was whether I had estimated the effort/cost involved in the management of Scott's project versus that of Amundsen. There are two answers to that question. The first is that if we assume that Scott did all the project management on his project and Amundsen on his, then both put in almost exactly the same amount of effort “ three years . The second answer is this, and it is not intended to sound clever. Amundsen had a successful project. Thus whatever the management of it cost, it was worth it. Scott's project cost the lives of five people. At this kind of price there is no such thing as an unacceptable overhead.