Though the title might seem a bit philosophical, this article will be about controlling projects and supporting PMs.
You may say it’s harsh, because if we have five-member team or one project to run, why would you need to control them. I thought that too, and I have to admit I was wrong.
Right now we have 120 employees at Divante and run dozens of IT projects at the same time. It’s a lot. We’ve got about 10 Project Managers and with this amount of tasks, it gets hard to give them all a proper support. Especially, when some of our projects are, let’s say, one of a kind, and all of them are difficult.
You’ll definitely find something about projects contole/ project portfolio in every project management methodology. PMBOK and Prince2 have special (and big) sections for this kind of matter.
I won’t bore you anymore and get straight to the point. How we do this in Divante to provide high quality support?
Team is the key
We’ve got an interdisciplinary team of 2 PMs, Technical Leader, Team Leader and me, CTO:) Thanks to this we can:
- avoid the informations overload – before we implemented this system I was the only person, who controled all projects, which I must say was pretty insane for me, as I had the other things to do at Divante as well. For sure, finding what might be a danger for our projects gets really difficult.
- support PM in every possible way – different expertise means different point of view, which helps a lot while trying to define the problem and prevent it before it gets worse.
Follow the rules
We all agreed to those rules:
- Trust but verify. Informations reported in all levels must be verified by at least one independent source. The best, and final source of informations is acctual website/ application we are currently working on.
- The glass is half empty. We expect pessimism from projects reports. It’s very important to escalate the problems, not only internally, but also to the client.
- No surprises. We don’t surprise our clients, nor the team, nor projects controle. If you do, thats some serious error in your system.
- Transparency. This applies to 100% of informations. We keep them sorted. We implemented DRY principle (http://en.wikipedia.org/wiki/Don’t_repeat_yourself) “Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.” Reports and informations about project are also understandable for the client.
- Trust. Divante’s culture is based on help and support, not punishments. This controle is meant to provide the highest possible quality of what we deliver with our work, and so we would deliver it on time.
To make those rules even more practical, we’ve modified them to suit our needs and that’s how they look like now:
- Trust but verify – reports are checked with other team members and sales team/ account manager
- reports are delivered by the end of every week, the day before status meeting (reports are read on the day of status meeting, that’s why it’s so important)
- cross-check – at least twice a month, half an hour talk with two programmers from the team and evaluator
- Toggl verification (if it’s kept up to date) + Toggl vs Redmine vs. Raport verification
- checking the progress and organising Redmine – every week before status meeting
- ‘lessons learned’ – team summary after finishing the project
- Internal demo
- at least twice a month
- project manager presents system functions – what’s been done so far
- all tasks set as ‘done’ must be ready to be presented (random monitoring)
- Earned value – as a progress control tool in a weekly test cycle
- performance chart + Redmine hours report + Toggl
- Transparency documents
- weekly report (according to templates prepared before)
- risk register (kept updated )
- open projects register (kept updated)
- updated schedule
- updated status in Redmine
This is not the perfect system, but if you run a big project (5-10 people involved, 6-12 months) I’m sure you’ll find it very useful. Though I’m open to your suggestions.
How do you deal with tracking progress in your projects and supporting PMs?