≡ Menu
Pawel Brodzinski on Software Project Management

What Would Be Your PM Approach: Steven Levy

In another post in what would be your PM approach we have Steven Levy facing three standard questions. Steven is an author of No Secret, a place where you can find stacks of great advices on project management and related subjects.

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.

Like any methodology, Prince-2 is mostly a codification of common sense. It’s rather process heavy, too rigidly so for my taste, but I gather there’s a refresh coming that minimizes some process overhead.

I would start off the project teams with a review of the first critical Prince-2 item, business justification. First, everyone should be clear on the ROI, when it starts to kick in given the various phases you’re likely to use, the sensitivity of return to project delays, and the sensitivity of return to features being dropped or deferred. This kind of work will help focus the team on must-haves vs. nice-to-haves, and may help order the task list for various phases so that as much as possible is as usable as possible as soon as possible (much-usable-soon). The other part of understanding the business justification is to ensure that the project team has some real understanding of the business itself, can speak the business’s language, and develops a feeling for sniffing out all the stuff they need to know but haven’t asked about. Every business makes assumptions based on stuff that is just “common sense” to them but that outsiders don’t understand.

Time/budget overruns are the rule with software projects, which is the area of my expertise. If they’re within industry average and the business understands this, I would focus more energy on delivering much-usable-soon. If you hit that target, you’ll minimize overruns because the tail end will be stuff you can drop or simplify anyway.

Finally, I’d try to get the team focused on the seven wastes of lean manufacturing. If it’s a software project, I’d use the Poppendiecks’ take on the seven wastes. If nothing else, this will tell me who is so process-focused that they can’t see the forest for the trees. In the long run, this will help the project team make common cause against waste and stupidity rather than against each other. (Well, sometimes it works that way.)

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.

QA in chaos is a true disaster – for their customers first and foremost, and thus for the company. That’s the first thing I’d try to straighten out. I assume you truly mean QA and not just QC (“test”); QA has to be built into the projects.

Next, I’d go to the dev team (including program managers, etc. – not just coders) and take their temperature. Do they think everything is working for them? If so, then there is a big problem; they’re not customer focused and are playing with expensive toys… and someone else’s money. I’d be starting on a big education project. If not, it’s time to partner with them to drive toward a working environment.

Then – what’s the overall goal of the company and the team? Ship great product? Make money? Stay in business? That’s something everyone needs to be on the same page about.

Finally, I’d try to figure out what everyone’s goals are in the job – not what they might put down on a management-by-objectives chart, but what they really consider success and happiness at work. I’d ask them to score themselves against these goals. (This would more likely be a series of hallway discussions and office drop-ins than a survey, though as soon as I got back to my office I’d write it all down.) Then I’d work up a plan that would both help them get closer to their goals and help get some stuff shipped on time.

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.

I assume, if I organized it, I have found an outstanding lead developer. I’d make sure he or she understands those must-haves – performance, availability, and whatever quality means in context. The others on the team will take their lead from this person.

Then we’d all work together to set up goals, milestones, etc.

Finally, assuming we’re all in one space, I’d put up a big information radiator – a bulletin board with each task on a card, pinned along a timeline, with a big you-are-here arrow pointing to “today” and reset each workday. When each task is complete, it comes off the timeline and goes into a big celebration wall – and we all get pizza, margaritas, whatever makes it feel like a celebration for each compete task. Any task that remains on the board left of you-are-here stands out dramatically and will force the entire team to focus on pulling as one to get it done.

Needless to say, if this is a new type of system, tasks will be rethought, new ones will be discovered, etc. Still, this very lightweight project management (that doesn’t feel like project management) is a pretty good way to keep it all together and moving toward the release. It also instills a culture of if-something’s-broken-it’s-public-and-everyone’s-responsibility-to-fix-it, which will be passed along to new team members as they join, and which I hope will carry over into the future when somewhat more formal project management is appropriate.
What these all have in common:

• Removal of waste – bad processes, less valuable features, poor communication, etc. If I have a consistent “methodology” this is it – lean software development, lean management.

• Simplification

• Communication – getting everyone on the same page and working toward the same (business) goals.

You can also check other posts in the series.

in: communication, project management

1 comment… add one

  • Todor July 24, 2009, 4:34 am

    IMHO, the best in the series so far!

    We all need to apply common sense and get it to the personal level with our co-workers.

    Made my day, thanks, Steven!

Leave a Comment