What Would Be Your PM Approach: Scott Berkun

This is the last, but definitely not least, episode of What would be
your PM approach series. For the grand finale I chose Scott Berkun,
who I don't need to introduce to anyone here I guess. Let me just
state that when I found Scott and his writings for the first time my
thought was "Hey, that's the kind of person I wish I'll be someday and
I'd really like to build similar blog somewhere in far, far future."
It's still an ambitious plan even though I don't consider myself
capable of writing such great books.

Over to Scott's answers.

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.

I'm not much for methodologies. If I have a method here it's two
things. First find out what my assets are. Who are the best people on
this project team? What are their strengths? Second, what are my
liabilities. You mention one: they haven't worked with each other
before. That's a big problem. My first move is to get a core group of
the best people to agree on the goals, agree on our top concerns, and
agree on a plan for addressing the concerns.

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.
I have to start small. I have to find a small project, or a small part
of a larger project, and release something good quickly. I need to
demonstrate that good work can be done in this organization. Once I
can show a small example of success it will be possible to get people
optimistic and motivated to replicate that example. It might even be a
small update that only takes 2 weeks, but if I do it on time, on
budget, and will good results I have an example I can sell to other
people on the team.

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.

If I'm at a startup it's critical we all agree on those strict
requirements. If one of the four disagrees, and writes code with his
own requirements in mind, we're fucked. I'd work very hard to
continually make sure we're all on in agreement on how to manage those
strict requirements, and invest our time with the same priorities.