Prototypes are something every software developer comes across in his lifetime. Usually quite informal in the early stages of their career by coding by the trail-and-error-pattern where every iteration can be seen as a prototype for the next. Later on, with projects getting bigger, it is most likely that the programmer starts to use prototypes more systematically. Some even learn to formalize them and use them in a professional way. In the end, software developers can be categorized in two groups:
- Those who see prototypes as a build-product in early stages of software development which improves project quality and resource planning by testing certain aspects and/or try new methods to create the product and which must be thrown away before the actual project is started to reach best possible product quality
- Those who do not care so much about all these words and just like to code straight away
From how I wrote this, you might get an idea which philosophy of those both I personally prefer. But I’m not one of those who take the proceeding too seriously. I regard the prototype as a piece of software which I use to analyze and gain information to compensate missing knowledge. This might be because I want to learn about a new technology or because I want to try new tools. Or because I never worked on a similar project before – which should be quite usual for a ambitious software developer. But I do not regard it necessary to create a prototype for really every project I work on. Sometimes it is possible to just determine one.
As the experience of the engineer increases, it is sometimes possible to find old projects which just can be looked at from another new point at view. Or it is possible to find another project which fulfills similar aspects to what one intends to work on. This approach however requires a highly skilled engineer as it is a difficult task to gain knowledge from a foreign codebase. Especially if the requirements or the design of the foreign project was not documented. This is sadly quite often the case in available open-source projects. In this case the gain of knowledge is close to zero.
Talking about project planning and project management it might sound obvious to state that it is quite useful to write down everything what gets decided. In fact many things seem to be obvious for those who are involved with the project. Usually the longer the time used to prepare a project, the more things get obvious.
When the first meetings to determine goals of an upcoming project take place, the discussions are very controversial. As a result, the protocols of such meetings are quite useless. But the more the expected results are discussed and outlined, the more things get obvious for everyone involved. As a result, the protocols are quite useless. Not again!
So the challenge seems to be to write down what everyone thinks is so obvious that it does no further discussion. But this is really hard work. Usually in every project there is a leading party. This may either be the customer for other-directed projects or higher ranking management for self-directed projects. The leading party in a project is the entity in the meetings whose opinion counts the most. And it is usually this same party which thinks everything is obvious and everyone in the room just likes to have a cup of coffee in a meeting.
The real challenge is now to find someone, who is willing to collect all those obvious informations and put it in a readable way which actually makes sense. This is actually a threefold challenge:
- Usually the information must be collected by filtering the important parts from everything what is said
- This has to be supplemented by all the information what has not been said but seemed obvious to the leading party
- The result has to be taken seriously by everyone involved in the project
Part one is usually hard enough as one soon finds out that everything said in a meeting usually does not make any sense at all when put together. So, this information has to be organized and “straightened”. But furthermore it is necessary to add all those details which are not spoken out. Actually not all of the information. It should be sufficient to identify what the leading party thinks is obvious and unnecessary to mention. This requires a very good knowledge about the project – which aspects of it are important but not discussed so far – and the leading party. The last point is the reason why usually the early stages of project planning lack of good documentation: No one really cares.
But it is of great importance that the documentation of the general project goals gets approved by everyone involved. If there remain white spots or even points of disagreement the whole project is most likely to be doomed.
Please note, that I’m talking about the very early stages of a project here. When I write about formulating the goals of a project, I’m not writing neither about the requirements specification nor the technical specification. Far before those very formal documents it is usually beneficial for a project to put the global requirements into terms. Especially when these are neither very specific nor very detailed yet!
In my last post I postulated 18 points of inevitable steps in software development. Now I want to explain some of them. Let’s start on the top
First and – in my eyes – the one most important point is to organize the project evaluation itself. This might sound trivial but is most likely to get forgotten in the whole process. The reasons for that are diverse but one can classify them in two categories: other-directed projects and self-directed projects. An example for the first category are customer-ordered-projects whereas the latter could be normal product development e.g. implementation of a new major feature. In the first case, planning the planning is often omitted as a customer offers his own ideas on how things work. In the second case almost the same is done by some higher-ranking management person. Why first listen to those who should do the work when you already have a phantasy of what will happen? Never confront illusions with reality seems to be the devise here.
Everyone involved with project planning knows this situation: The idea of what the result of the project might look like has just been vaguely, informal described and now you are asked “Tell me, how long would it take?”. And now you are asked to compete with an absurd small period of time without any ressource-planning being made. And no matter what you answer – you suck! The worst thing you might do is to give an answer which can me interpreted somehow as if it is possible. But usually you should have enough knowledge in this situation to give at least an time-table what to do until you could answer this question and how long it might take. This is 1. because you got this position somehow and 2. hopefully for a good reason.
I’ve heard and seen a couple of cases where the give timeframe until the project can seriously be evaluated was far beyond the absurd assumption made previously. In this case you can either
- try by ignoring that you do not have the slightest idea of what the result will look like
- you are convincing that the time is necessary and either worth or the project is doomed or
- quit the job
Most project managers decide for the first option. As a consequence software development is most often somewhat of gambling where you can only bet whether the current project is doomed or keeps being dissatisfying. Please note, that the latter options is the more favorable one. Sad enough.
No one working in software development would doubt that project planning is necessary and important. But one may doubt that anyone knows how to do it. Actually I don’t remember someone ever telling me that a project plan worked out just fine. But I know a lot of stories on how project plans just failed inevitably. And before I post something about the my greatest failures in project planning – this might come later – I want to write about how to frame a project plan which respects the most important aspects from my point of view.
First I will draw an outline of the project:
- Set a timeframe for project evaluation
- Determine and formulate the goals of the project
- Create or determine an prototype
- Determine and formulate the gained cognitions
- Determine and formulate the positive and the negative aspects of the prototype
- Revisit the goals of the project
- Evaluate the project: time-constraints, resource-constraints, quality-constraints, expected results
- Sketch out a project design
- Build a sophisticated project infrastructure!
- Split the project into tasks and assign them explicitly
- Create the implementation
- Check wether implementation fulfills the project goals
- Mend the implementation
- Check wether implementation fulfills quality standards
- Improve the implementation
- Create Documentation for usage, administration, configuration and deployment
- Approve the results of the project
- Deliver or use the results and be happy with it
Yeah, I know there are about a gazillon of different models for projects plans out there. So why come up with a new – such informal – one? The reason is, that all of this points must be done at some point, no matter what the project plan layout looks like. Whether you are working in a scrum-like-pattern or with a fully elaborated derivation of the V-Model. So this is not an alternative model made by some who thinks he can easily reinvent everything because he likes to ignore textbooks. This is merely an enumeration of what is unavoidable in a software development process – and nevertheless most often done wrong!