≡ Menu
Pawel Brodzinski on Software Project Management

How Do You Look at Your Project

At the moment in my team I fulfill several different roles. I’m a team manager, a project manager and a business analyst. I co-own the product. I (hopefully) help with architecture planning and design. I make use of my knowledge about usability and take my share of testing. I’m a frequent attendee on business meetings with customers. It’s a typical startup-like environment, where everyone needs to be a little bit of this and a little bit of that.

This gives me pretty unique perspective as I can see our project as both a forest and group of individual trees. It doesn’t scale up endlessly however. If you don’t want to agree on that you’ll learn the lesson hard way. As project, or product, grows project manager has to focus on few areas leaving other ones for the rest of the team.

It’s enough to have a dozen people in a project to reach a point where it’s extremely hard to have knowledge about every important detail both technology-wise and business-wise. With a few dozens of people it’s virtually impossible to do so.

As a project grows you have to agree on a number of tradeoffs when it comes to your knowledge about the project. Basically you can choose one of three ways:

1. Technical expert.
You know every detail of architecture and technical design. You can face whole technical team of the customer alone and win the confrontation. You can find a solution of the most difficult technical issue which appears on the way. The rest of the team most likely follows your ideas as they’re most of the time good ones. It will work well in teams which are able to self-organize or doesn’t need strict supervision. It’s also a very suitable approach to projects ordered by customers with very high technical knowledge (not only software engineering but also market-specific) as it often happens in telecommunication to give the example from the top of my head.

2. Business case keeper.
You understand the business standing behind whole project. You can justify every technical decision with business aspects of the project. You know what customer wants to achieve, how they’re going to do this and what has to be done on the technical side to enable the whole scenario. The team deals with all technical issues and you don’t need and don’t want to mess with it as you’re mostly a business person. This approach is useful when you have a team of geeks – people who eat a bunch of complex software problems for breakfast and begs for more. Unfortunately they also tend to look for complex technical problems to solve even when there are none. At the same time they happen to forget that in the first place project should deal with business issues not technical ones and it happens oh so often that the best solution is also one of the most boring one.

3. Guru organizer.
You have experts all around you. For each specific question you can find a person who knows the best answer and has way more experience in the area than you’d ever have. It works that way both on technical side of the project and on business side. Everyone will do their best, as far as they’re told what they’re meant to do and they’re assigned to areas they’re experienced in. Unfortunately the team is pretty big and cooperation between team members doesn’t work perfectly. Most of people tend to focus on their own tasks leaving the rest for the rest. And this is exactly your role – making the whole mechanism working flawlessly. Being a messenger, task-setter, feedback bringer, coordinator and communication booster. You spend all-day long organizing people work so their effort can bring best results. This approach will work well whenever a project team is gathered only for this single project and will be disbanded later. It’s also a good choice whenever you have experts from all areas on board and you don’t need to cover any specific area of the project very deep. You can allow yourself to see a project only as a big picture but at the same time you need to see people interactions as a series of small details. In very big projects PMs, they want it or not, are forced to choose this path as there’s some limit in number of people who are able to self-organize.

Of course there are all flavors of these but usually there’s one strong path we follow, trying to keep our finger on the pulse. This time I’m yet to choose mine, although I guess I already know which role I’ll end up with.

And what’s your role? Which kind of project manager you are? Or which kind of project you run?

in: personal development, project management

0 comments… add one

Leave a Comment