Software Reality
Programming with
a dose of satire.

Site Map Search

Agile Development
Extreme Programming
Code Generation


Use Case Driven
Use Case Driven Object Modeling with UML: Theory and Practice
Get from use cases to working, maintainable source code. Examples use Spring Framework, JUnit and Enterprise Architect

Agile UML
Agile Development with ICONIX Process
A practical subset of agile development techniques, illustrated by example

Get Controversial!
Extreme Programming Refactored
Extreme Programming with a dose of satire
Available now:

Java Swing
Swing's greatest threat isn't SWT, it's Flash
Swing Survival Guide

Check out our ageing Reviews Section


Research Projects: How to recognise them, deal with them and survive them...

Slippage and Research Projects

By Matt Stephens
March 11, 2002

Project slippage is a common ailment, particularly on "urgent" projects where rapid development is paramount.

"An arbitrary milestone put in place to help track progress"

At its most basic level, project slippage is simply the act of missing a deadline. The deadline might have a business imperative attached to it, or it might simply be an arbitrary milestone put in place to help track progress. Either way, when slippage occurs, it looks bad.

Why does slippage happen? These days, we have the most accurate tools and techniques for estimating timescales, so in theory at least, each milestone should be reached on the exact day that it was estimated.

This is never likely to happen, of course. You can guarantee that the one day on which a milestone will absolutely NOT be reached, is the one that was predicted in the project plan. There are all sorts of random events that can cause even the best thought out schedule to slide off-base: illness, coffee breaks, meetings, unforeseen design consequences. All these and more get thrown into the entropy pool that is plan realisation.

Nevertheless, all these unexpected events can be taken into account, to an extent. Based on previous projects, for example, you can predict that on average x out of y days will probably be lost due to the sort of random events mentioned above.

The biggest killer, however, is the ailment known as the Research Project.

"Any project that is unprecedented"

The Research Project is any project that is unprecedented, in whole or in part. By "unprecedented", I mean that something of its nature has not been written by anyone in your organisation (or more importantly, by anyone in your project).

Such a project is unavoidable. Neither should you WANT to avoid it - it's the discovery and invention of new things that makes software development so compelling. But without recognising that something is research, that which is compelling also endangers the entire project.

Why are research projects potentially so dangerous? Simply, because you (and the entire team) don't know what is involved, therefore you can't know how long the work is going to take. If this hasn't been done before, your programming team will go down numerous design blind alleys before settling on a suitable design that fits into the overall architecture.

Chances are that the overall architecture will have to be adapted to suit the design. If something is going to be redesigned many times over until it is finally deemed to be correct, it is impossible to say exactly how long it will take to complete.

"Planning improves with experience"

The usual approach to project planning is to base estimates on similar work that has been done before. As a result, planning is something that improves with experience. Even unprecedented work can often be based on similar past work. Complications arise when the work was done by different teams, with different abilities, levels of experience and so on.

The temptation is to put estimated timescales in the project plan, primarily to keep higher management contented. Of course, these timescales are merely random estimates intended to produce a vague (almost meaningless) set of milestones. Even if you THINK that people will recognise this - or even if you TELL people - the timescales will still be regarded as being set in stone.

It's human nature to regard something written down as a contract, or even sacrosanct. The age of a written document also seems to contribute to its perceived importance - the older a document is, the more sacred and infallible it must be. Amazingly, this perception even applies to project plans and out-of-date architecture diagrams (see Obsolete Documents).

The Research Project is an insidious beast - primarily because it creeps into production projects, such that those involved do not even realise that they are performing research. Anything which involves a programmer sitting back and thinking: "Hmm, I wonder how I should do this..?" involves research.

More often than not, a research project will not have been flagged as such. It probably does not occur to the project manager (let alone the designer or programmers involved) that they are really doing research. But it's vital that they do. This is a pivotal moment when projects are either doomed on the spot, or kept alive (at least until tomorrow).

When does a production project become a research project? Unfortunately there is no "black and white" answer, because it won't be the case for the entire project. Only a subset of the overall system will be unprecedented.

Depending on the granularity of your architecture, you should be able to identify specific modules (and/or subsystems) that represent unprecedented work (i.e. are Research Candidates). Having identified the Research Candidates, the next stage is to try and estimate the impact that these areas will have on the project as a whole. If your codebase is truly modular, then only the Research Candidates will be affected.

"Estimating the impact on other modules is more difficult"

In many cases however, and sometimes unavoidably, the classes that interact with the research modules will also be affected. Pinning the Research Candidates down to specific modules is easy, as long as you have a way of determining which modules are unprecedented. Estimating the impact that they will have on other modules, however, is more difficult. Unfortunately, it's an acquired art rather than a science.

The vital starting point, however, is simply to acknowledge that certain parts of the project will involve research, therefore constitute a risk to the success of the project. Until you know what the research modules involve in order to implement them, it is impossible to know the real impact that they will have. Therefore, all research modules should be flagged initially as high risk.

If you prioritise work according to the level of risk involved, then this means that you should attack all the research modules as early as possible in the project. It's the quickest and least risky way to avoid project slippage.


Steps involved in recognising and surviving Research Projects:

1. Acknowledge from the outset that at least part of this project involves unprecedented work.

2. Identify those modules that are Research Candidates, based on:

a. Whether or not a similar module has been written within your organisation
b. Whether any part of the module will involve the programmer thinking up a new design

3. Assign a risk level to each Research Candidate, based on:

a. Estimated work involved
b. Number of other modules affected by the design of this module (e.g. changing the interface or expected behaviour)
c. Number of other modules that rely on this module (directly or indirectly)
d. Whether this module represents new technology (i.e. nothing like it has ever been written before, either here or in other companies)
e. Whether established Design Patterns, pre-built components, "how-to" books etc exist for this type of module.

4. Schedule the Research Candidates to be written first. Expect the first few attempts to be throwaway code - prototypes.


Top 10 Practices to Survive Research Projects:

10. Know your team. More importantly, get to know their skills, strengths and weaknesses as early as possible. You will have to know this anyway, in order to allocate them to specific tasks.

9. Always talk to your team. Don't assume that each person can or cannot do something.

8. Be aware that if your team say they can do something, that doesn't mean they really can. It's possible that they just don't want to seem stupid; or they could be hoping for a pay rise.

7. Encourage your programmers to produce prototypes for Research Candidates, before writing the real thing. Act very surprised if they opt to keep the first version.

6. Allow time for prototypes. Make this very clear and obvious in the Project Plan.

5. Employ Agile Methods, where appropriate, to help drive the design (but do recognise the difference between changing requirements and a changing design).

4. Be prepared to throw away research code (i.e. prototypes).

3. Keep the knowledge and the designs won from the research.

2. Clearly mark Research Candidates in the project plan.

1. Always plan extra time for Research Candidates (for prototyping, and to allow for programmers' learning curves).


Related Articles:

Fear of Non-Progress

Obsolete Documents

<< Back to Lifecycle

All trademarks and copyrights on this page are owned by their respective owners.
Stories and articles are owned by the original author.
All the rest Copyright 1998 onwards Matt Stephens. ALL RIGHTS RESERVED.