Today’s Project Management Lessons Learned originally come from IT, but I’ve found that they can easily be transferred to most other development projects as well: My project teams include a wide variety of people, characters, pragmatists, nerds, team players – all of them great specialists in their respective fields. We all have the same goal, which is to deliver our project as well and quickly as possible. But everyone has a different story about how they got to where they are today, what role models they had and what they drew from them. So, everyone has their own style of doing their job.
A project manager has to deal with this and integrate each individual with his services. And/or consistently demand the things that threaten to fall behind individually. The best example is the high aversion to documentation among developers. Developers want to develop, tinker, create great results. But the paperwork is boring and time-consuming, and besides: “You can see it all from the code or the drawing !” It is strange, then, that even the “producers” without a clear task and development documentation usually find it difficult to define usable test criteria and test cases. And this causes increased effort for the testers and test engineers at the latest – at the expense of the project budget.
Regardless of this, the project manager must always make sure that the project results are comprehensible and representable. So that others who later (perhaps in a completely different project) work on it again and possibly have to change something, can find their way around and go to work without major problems of understanding.
After all, the goal should not only be to ensure that project results work, but also that they can be used in the long term.
Read more Lessons Learned…