Software Project Management
Why hire us?
Products and services
Our recent clients
This report is a summary of ideas on Software Project Management collected from various sources. The motivation behind this is to get a better understanding of software project management in order to help Runtime projects run smoothly.
Fabrice Retkowsky, October 2000
1.1 Rapid Development
Written by Steve McConnell (Microsoft Press), this over-long book is considered as `must-read'. It's split in two main sections: the first 390 pages define the principle of Rapid Development, the main issues of project management, how to tackle them, and hints at `best practices'. The second part is a catalogue of 27 such `best practices', i.e. techniques that projects could/should use to achieve faster development.
1.2 Death March
A short book by Edward Yourdon (Prentice Hall). Two or three chapters (at the beginning and the end) are kind of useless, but the core of the book is more or less a very good summary of Rapid Development, with some extra ideas.
Second edition of a classic by Tom DeMarco and Timothy Lister (Dorset House Publishing). This one is about people and their environment, not about software project management. There's no technicalities there, only general observations of people and places full of common sense. The authors take from various sources, incl. some Alexander stuff. It is extremely good reading and short (230p.).
1.4 ACS 4.0 development notes
aD has some documentation on the development of ACS 4.0 on its website. Most of it is private, but some is public and shows the kind of management tools/methodology they use or used.
1.5 Further readings/resources
According to Rapid Development, there are 4 steps to efficient development:
If you think about the development speed of a project, there are four dimensions to take into account:
Estimates (within the context of a requirements specification, or during the process of a project) have various objectives: knowing how much effort a project will take, how much time it will take, how much resources it will require.
3.2 Lack of accuracy
However good the initial requirements capture is, statistics say that early effort-, size- and schedule-estimates will have a very low accuracy (Rapid Development):
Hence we should be honest to clients and give them margin estimates such as ``this will take between 3 and 6 months, probably 4, we will know more precisely in one month's time when the design is complete''. We should take a `cooperative' tone when talking to the client: ``We can do it together, it's not good for both of us not to have more precise estimates, but as soon as we'll know we'll tell you''. Telling the `estimation story' is an important part of client relationship (Rapid Development p. 172, 198, 201, 325). Rapid Development also gives advice on Principled negotiation (p. 222, 503) and Theory-W management (p. 559). The focus of Principled negotiation is on interests (not positions), by separating problems from people, using objective criteria, and finding options for mutual gain. Theory-W management, which is based on principled negotiation, consist in making ``everyone a winner'', by identifying stake-holders and their win criteria, and then finding win-win conditions where everybody wins (rather than I win - you lose).
Programmers always get their estimates wrong by minus 20% to 30%. This means that they should always be asked for estimates, as they know best, but keeping in mind their margin of error.
Finally, resources and feature set never match from the beginning of a project: clients always want more than they are ready to pay for. Resources and features therefore will have to be revised in time so that they end up merging by the end of the project (or hopefully before that).
3.3 Improving accuracy
A lot of the inaccuracies of estimates stem from the estimator's ill-judged belief:
The requirements should be drawn with a strong client involvement. The client is the one who can say what he wants, even if it takes time for him to say it. Rapid Development insists on this customer-oriented development (cf. Joint Application Development, p. 449). We should keep in mind to cut down on specifications early (as the client will always want to much).
There are various techniques for information gathering:
The requirements specification report can/should include:
Rapid Development gives a general estimation methodology. First, estimate the project size: either with function points (which is probably too complex and not so reliable), or in man-months/days. Then, from the size, estimate the cost-optimal effort (team size) and schedule (duration). Rapid Development gives a formula and 3 tables for this (p. 183). For example, a 20 man-month project should be done in 8 months by 2 ½ people. Don't forget to always give results in the ``between 3 to 6 months, probably 4'' format, or using quarters (``by 3Q01''). And always account for extra tasks, such as testing, integration, showing staged releases to the client, modifications, manager time, on the phone, etc.
For the NEC ecommerce project, what we did was to account for all the coding which was quantifiable in man-days first, then double it because of testing, then add a 2-week buffer at the end of the project for integration purpose, and finally add an estimated manager time (e.g. half a person over the whole project).
3.4 Negotiating the costs
There are 3 dimensions to the negotiation process (Rapid Development): Schedule, Cost, and Product. All three of them have to be balanced. If a client chooses 2 of them, we have to tell them what the 3rd has to be.
Don't hesitate to ask the question: is time really the issue? Is it not simply something else? Scheduling for an (over-)tight schedule won't make things happen more quickly - rather the opposite: it will take longer in the end, and be more costly (in terms of money, people, everything). We have to find acceptable trade offs. Death March gives a few negotiating games (p. 80). And if the terms are still not right... don't hesitate to walk away. Or to resign...
3.5 Evolving the requirements
Requirements should be revised and made more accurate in time, in a supervised way, usually by the project manager via weekly requirements review, with associated cost and schedule reviews.
The client will always want some feature changes. This can be minimalised by:
In the event of a schedule slip, multiply the slip by the ratio of the project done to estimate the final slip. If after 2 months of a 6-month project we are 2 weeks late, we will end up 6 weeks late. Don't think otherwise.
Besides, use the principle of Triage: categorising feature priority. Some features are must-do, others should-do, could-do, etc. Or use a numeric scale.
The whole chapter 5 of Rapid Development deals with risk management. Here are some classic risks:
Risk management consists of both risk assessment (identification, analysis and prioritisation) and risk control (risk-management planning, resolution, monitoring). A list of risks should be drawn from the start of the project. This list should include all potential risks, their probability of occurring, the size of the potential loss (e.g. in man-weeks), and hence the risk exposure (in weeks), as well as ways to prevent them, and/or to tackle them.
The list should be prioritised, and not simply by exposure. For example, a risk with a 4 months penalty, even if it is extremely unlikely, will come top if the project deadline is in 2 months' time and is of utmost importance.
The list should be reviewed regularly, for example in the form of a weekly Top 10.
aD had a tiny risk list for ACS 4.0, they didn't seem to take it too seriously.
A final note: it is important to plan for risks - but not to eliminate them. Companies using e.g. the `Capability Maturity Model' Big-M Methodology will end up evading risky projects, which are usually the most profitable ones (Peopleware). Better take on risks as research or internal projects, and always be aware of them and budget accordingly.
Rapid Development gives a complete list of classic mistakes to avoid (p. 49). We should learn the most important ones, and go through this list regularly during the whole length of a project.
All books insist on the role of motivation. Rapid Development adds that the motivation of programmers differ from other employees (e.g. managers): personal life and achievement take a much stronger place.
Most books talk about overtime as being too common. Peopleware has long sections on workaholics and overtime. The general point is that both are dangerous, for individuals as well as projects on a whole. The problem of workaholism: ``the loss of a good person is not worth it''. Problems of overtime: the negative aspect can be substantial (error, burn-out, accelerated turnover, compensatory under-time), and teamicidal repercussions on otherwise healthy work groups. Finally, overtime should always be kept track of: otherwise it could ruin schedule estimates.
At the same time, Peopleware develops the idea of `intrapreneurs': the (very few) members of staff who are so good on their own that they are let to define their own task, and who, whatever they decide to do, always end up benefiting the company.
Finally, companies should help people retrain themselves completely if they want to/need to. All books insist on the overwhelming weight of losing a member of staff and having to replace him/her (it could be equivalent to anything between 3 months to 1 year of salary).
Rapid Development give guidelines for team selection:
Rapid Development also gives a list of team structures (p.304), and Death March a list of team roles (e.g. roles of individuals within a team, p.115). An important aspect of all of this is that each team should have at its head a project manager/technical lead pair. Both roles are distinct and should be taken by different people. The technical lead looks after the project development from scratch to finish, while the manager takes care of client relations, before, during and after the project.
Once a team is formed, it should be given one main aim, one priority, one goal towards which all efforts should be focused. During the progress of the project, individuals should be given smaller-scale targets, such as a weekly aim, or even a few daily mini-milestones.
Good communication between team members should be promoted. Managers should trust people (and show it), particularly within the team they manage. `Someone you don't trust is of no use'.
Managers should also try to re-inject small amounts of constructive disorder into an activity which is getting more and more ordered and rigid (Peopleware). Examples: pilot projects (but don't experiment with more than one aspect at once), war games, brainstorming (with no evaluation of proposed ideas - that's for later), provocative training experiences, trips, conferences, etc.
Hopefully new teams will end up developing an identity of their own, or even `jell' (Peopleware). Jelled teams are a bunch of people who work together easily, who feel unique and possibly superior to others, who develop their own jargon and private jokes, who feel like a team. They should have a cult of quality, and enjoy the feeling of `closure' (the end of a *completed* project). And they can't be controlled in anyway, so managers shouldn't try to.
Finally, Peopleware (again) explains that the adaptivity of a company as a whole is usually based on its strong middle management, i.e. whether middle-managers cooperate towards improvement.
Peopleware comments largely on office environment:
Bad symptoms: when people hide out to work, when they prefer to work from home or anywhere else than in the office, when ``nothing can be done here between 9 and 5''.
On interruptions: it takes 15 minutes for someone to get into `flow' mode, where work can be done efficiently. Any interruption (phone call, someone talking, loud speaker, alarm) will cost you that much. Don't count how many hours you spent working everyday, count how many non-interrupted hours you managed, and don't be surprised if it is 0 at first. The ratio of the later on the former varies from 0.10 to 0.40 between organisations. For one, I changed my cute `you've got mail' animation on my desktop to a very lame text-only thingy - I can ignore it much more easily, and it doesn't interrupt me anymore.
On music: people can do our kind of work fairly easily while listening to music, because listening to music and doing our kind of work don't use the same side of the brain. But experiments showed that listening to music kills creativity (or nearly). Don't expect to come up with as many time-saving smart design solutions if there's some music around (Peopleware).
On office space: let people who fit together put their desk near each other's. Let people organise themselves (organically). Peopleware quotes C. Alexander stuff (architectural patterns, Timeless Way of Building, etc.). They mention 4 more patterns:
Here we're speaking small-m methodology. None of these Big M standardisation madness (Peopleware).
7.1 Development strategy
No-one should really use the rigid waterfall methodology (make requirements and then stick to them blindly). Rather use more flexible methodologies where requirements are refined and changed within a constrained process. The most suitable methodology depends on the situation. Examples:
All these methodologies sound similar, some are delivery-focused, others more prototype-focused. The focus may change during the development process, more prototype-focused at the beginning and delivery-focused at the end. The user/client involvement may change as well, from being feature-oriented to being bug-oriented.
Rapid Development gives a table which can help choosing the most suitable methodology according to various criteria. I did it for one of our projects, and it confirmed the first impressions by ranking spiral and evolutionary delivery as best methodologies, but it also gave `design-to-tools' as suitable (a methodology where the product is limited to what the toolkit can do).
7.2 Development management
Death March names a few formal processes such as ISO9000 and SEI (p. 144/147). But Peopleware reminds us to stay clear of Big-M Methodologies.
In terms of tools, Death March: Estimacs (Computer Associates), Checkpoint (Software Productivity Research) and Slim (Quantitative Software Management). aD was using MS Project 2000 at the beginning of the ACS 4.0 project, but stopped using it after a couple of weeks and moved to Dev-Tracker (by Abante, who don't advertise it on their own website). We should find out if there's such a tool for Linux, one which outputs HTML if possible.
It seems all methodologies/tools turn around the same principle: that a list of tasks should be drawn, with their duration estimate, a staff assignee, the percentage of completion (and how much time it took to get there). With such a table it is possible to know what tasks are on target, whether there is already any delay, etc. And don't forget that over-time should be included.
Besides having assigned tasks, developers can also be given milestones. Some advocate mini-milestones ( a few every day), it is important to have at least weekly targets.
The manager should every week spend some time to reevaluate the project:
Never think that some things are not measurable (Peopleware). Gilb's Law: anything you need to quantify can be measured in some way that is superior to not measuring it at all. This can have a cost of course. And keep management whatever happens - particularly if project is not doing well.
7.3 Development practices
Using a flexible design will mean less rework. Quality is a means to higher productivity (Peopleware). It has an initial cost, but is cheaper in the end.
At the same time, reducing developer gold plating, and not doing research work within a tightly-scheduled project is important as well. Don't accept client requests for changes in requirements, and cut down on the specifications if possible.
All other comments on development practices boil down to one thing: testing. Testing, testing, testing, testing and more testing:
One final comment is about the programming tool set. According to Rapid Development, it should be kept minimal. This would allow programmers to see what tools are really needed before introducing them. Sufficient learning time should be planned before using them in real projects.
7.4 Coding practices
Code complete gives substantial information on coding practices (I haven't read it yet though). I think we should also come up with a list of specific coding practices for each toolkit we use.
Some suggestions for the ACS: