This weekend I read skim-read the book “Das Kommunikationskonzept” from Klaus Schmidbauer and Eberhard Knödler-Bunte, which is a guidance for developing a communication concept. My sister Verena Voges is using it at a reference.

I liked their approach to writing concepts which they divided in nine phases and will adapt it here for a general concept approach to projects/work.

The first three phases are analytic ones: briefing, research, analysis

The next three are more strategic: Goals and target groups, positioning, Core ideas/messages

The final three are then operative phases: Tasks, Measuring Success, Presentation/Documentation

It is always interesting to see how other disciplines structure their work and how they approach it. I think it is very valuable to broaden my own consulting tool set and it is helpful to borrow ideas from others. So if we map this concept with their phases to a Software projects I would adapt it as follows:

1. Briefing – What kind of problem do we have? Why do you want to have a new/better support by an IT System?
2. Research – What applications do you already have in place? What coding conventions/style guides/EA guidelines are in place?
3. Analysis – based on the information from briefing and research;  priorities, opportunities, guidance, ratings
4. Goals and target groups – describe target group/stakeholders for IT system and goals that would make it a success.
5. Positioning/Core principles (Two in one) – are we aiming for a lightweight or heavy solution? Web-Based vs. Rich-Client? Java vs. .NET? iterative approach? Using OpenSource, self-developed or COTS?
6. Solution/Suggestion – what systems will support which areas? How will we start?
7. Measuring Success – Budget and KPIs to measure if the business case was worth it, How can the improvements be measured

The last phase (Presentation and Documentation) is omitted since it is about presenting the concept and how to document the work. The first one is defined how we the concept/project proposal is submitted and the second one is pretty obvious in software projects. You document your work in a running system 😉

What do you think? How do you approach your work? Any other reading recommendations?

Next on my agenda is Design Thinking and the great book from Tim Brown Change by design. Watch this place for an update on this.