What Would Be Your PM Approach: Bas de Baar

This is the next to last set of answers in What would be your PM
approach series. This time our guest is Bas de Baar who I believe you
know from Project Shrink. Bas is also the author of Surprise! Now
You're a Software Project Manager book.

There are three situations. For each the question is the same – what
would be your project management approach?

You work in a big company and are put in charge of big complex project
which is about to be started. People in the company are familiar with
Prince-2 but time or budget overruns aren't anything new, although
they're kept at industry average level. A project team is gathered
from different teams – they haven't worked with each other on any
project yet.

In principle I would work with whatever method is dominant in an
organization. Just have to make sure that they are really working
Prince-2 and not some Prince in Name only scheme. Start with a
workshop to align everyone's perspective on what it means running
under Prince-2. Essentially making sure we all are using the same
rules of engagement within the project. Make sure that the business
case is being understood by everyone involved. Have the business
executive present a stunning view of the project goal. Create the
context in which the project is running. Everyone should know why we
are doing this. I would really spend a lot of time making sure people
understand their role and know their contribution to reaching the
overall project goal. Make the rounds and speak to everyone. Stimulate
conversation between different members.

You're hired to clean up the mess in projects in company of 70 people.
So far the company struggles to do any project on time or without
major problems. Project management is pretty non-existent and software
development along with quality assurance is drowned in chaos.

First I would make sure I understand the problem, and remove any
obstacles (if possible). Concerning the approach, introduce a small
and easy method that everyone can understand quickly; Scrum comes to
mind. I would make sure everyone understands the method. Make
rigorously sure everyone performs the steps (after a short while it
will come naturally to the people). Let the executive communicate the
overall business goal, clearly without fuzziness.

You organize a startup of four people, including yourself. The idea
you work on however puts pretty strict requirements when it comes to
software performance, high availability and quality. The team isn't
going to grow for some time but in a perspective of year you hope to
see a dozen people on board.

Again, I would opt for a light weight process, like Scrum. However, I
would use the most strict software engineering practices available.
Have a great architecture. Make sure you start testing right from the
start, including the performance and availability criteria. Use peer
review and iterative approaches as much as possible for feedback.