A project plan frame

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:

  1. Set a timeframe for project evaluation
  2. Determine and formulate the goals of the project
  3. Create or determine an prototype
  4. Determine and formulate the gained cognitions
  5. Determine and formulate the positive and the negative aspects of the prototype
  6. Revisit the goals of the project
  7. Evaluate the project: time-constraints, resource-constraints, quality-constraints, expected results
  8. Sketch out a project design
  9. Build a sophisticated project infrastructure!
  10. Split the project into tasks and assign them explicitly
  11. Create the implementation
  12. Check wether implementation fulfills the project goals
  13. Mend the implementation
  14. Check wether implementation fulfills quality standards
  15. Improve the implementation
  16. Create Documentation for usage, administration, configuration and deployment
  17. Approve the results of the project
  18. 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!

Leave a Reply