Pragmatic Project Mangement

WTF? Pragmatic Project Management?

Programmers (aka hackers) nowadays are called the heroes of the future – and I can not agree more. If I were a programmer, I had dozens of ideas of what to do with my skills – imagine being a craftsman, who can build whole houses on his own – great stuff.

The only problem is: I have never been a *good* programmer – yes, I’ve build sites on my own, I have build nice sites for customers based on typo3 and PHP but it has always been more of a „find and put together“, than having a real concept and thinking of security, performance et all – programmers: I really admire your skills.

But what I have found is, my strength are combining creativity and technology, and I’m quite good in talking to developers and explaining them my ideas, so that they are able to build „the house“. That’s because I do have a quite deep overview of current technologies, there pro’s and con’s and know very well how to manage teams and projects (gosh, it must be more than 100 webprojects now in more than 10 years in that business for small companies to global bigships.)

My point is, that I haven’t found the best way how to manage programmers and stakeholders (like marketing managers) together yet. From waterfall to Scrum – I tried all methods from a 2 men to 20 men project team. But the problems still remain the same, which are:

– non programmers and dev’s do speak a *whole* different language

– stakeholders *never* have an idea, of how complex projects can be from a technology point of view

– developers *never* have an idea, of how complex it is to define specifications, sell or market a product

Especially in big projects, companies try to solve these issues by installing many instances of „Project Managers“ to handle the projectplan, the specifications, … But the bigger the team for a dev project gets, the complexity raises.

What I am looking for is a lean approach to dev projects – ANYONE should be able to manage a (web)projects – in the end its a question of trust, „language“ and responsibility.

Just ask „why“

Instead of writing dozens of specifications, instead of writing and discussing your daily scrum-tickets I would try to just ask: „Why?!“

Given the idea for a project from a marketing guy.

He should ask himself:

Why do I want that project to be build?

Why do I need a new design?

Why do I need a contact form?

Why do I need an RSS Feed?

Why do I need a CMS?

Why do I ….

Put that guy together in a room with a developer and let the developer try to answer the „Why“ questions which are presented by the marketing guy – this might be the hard part, but from that discussion, the dev gets the insights and it is in his responsibility to translate them into programming steps.

Then again, let the developer ask himself the according questions:

Why will I use MySQL?

Why will I use ruby?

Why will I write that specific function?

Why will I use that CMS?

Why will I catch that exception?

Why will I …

Put the both of them in a room again, and let the marketing guy answer the developers questions. And it is in the developers responsibility to answer them correctly and argue „why the hell“ it is necessary to do so. This again raises the understanding of the marketing guy of what the dev is actually doing, why he is doing it and from that discussions I see a very pragmatic approach, which will lead in a lean, pragmatic project management.

To be honest, this isn’t thought to the end with really big projects, but my point is:

– the developer has RESPONSIBILITY for every step he takes

– the developer has RESPONSIBILITY for the whole project

– the marketing guy has RESPONSIBILITY of what the dev will do

– the marketing guy has RESPONSIBILITY to get a clue of the programmers language