What is a scalable process of Project Management in Small Development Firms?

Question

We have a small company team and even smaller Development team. The current process is that each Sales Rep (SR) is the actual Project Manager of each web application sold. Developers obtain requirements, functionality and design from the SR directly. Giving the actual head of developers to visibility over the actual work load on the developers. While we get more projects and thus possible more Sales Rep and Developers this process gets not-scalable.

We have thought about having a Technical PM be in the middle between SRs and Developers.

SR1, SR2, SR(n) ---> TPM --> Dev1,Dev2

This seems ok, but our current process allows our Sales Reps/QuasiPM actually get developer time in a very immediate way. And they are actually trying to get aways of this.

The issues we are having with the current process are:

SR1, SR2 --> Dev1, Dev2 (Adhoc)

• No visibility to our Developers work load (Making developers have too much down time or too much work load)
• Not being able to plan vacations according to crunch times
• Edit1: Another issue that we forgot to post is that SRs are in morning meetings and priorities change per day depending on their emergency.

I will add more information depending on the comments I receive. Thanks for your time as always.

EDIT2: In general there are 3 SR or Product Owners, 3-4 Developers, 1 Technical PM.

Answer 1

For visibility, consider a board of some sort. We started using Kanban (one part of Lean) recently, and so far it appears to be a positive force. It attempts to even out the work load (or flow).

For vacations/planning, Kanban is one option. Others include XP and Scrum. IMHO Scrum is more a management philosophy while XP is a development methodology. Planning Extreme Programming is definitely worth reading.

Customers (your SRs) will always try to get around the development process. "Can't you just slip this story in to the middle of an iteration?" You need to get management buy-in and support on whatever methodology you pick. For the SRs, the benefits are (1) they get to prioritize the stories (feature requests) and (2) they'll have a better idea of when their stories will be done.

Answer 2

Don't put PM's between sales reps and developers. There are two unrelated issues here.

• What features are you delivering? (Only the SR knows this.)

• Are you making progress; are you getting things done on time? (This is what a PM is for.)

What you want is this.

sales rep -> [ developers + PM ]

Further, you want some structure around the interaction.

You cannot allow SR to drop random requirements onto the development team. Instead you want the developers to focus ("sprint") to a goal and produce something. Once they finish a sprint, then they can meet with PM and sales folks to determine what the next sprint is.

This is the Scrum method, and it scales well. It controls interactions without putting additional people in the way of the interactions.

Answer 3

I would focus on your current problems versus picking a whole new process. If your primary issues involve working tracking, install a time tracking system. It will show where developers are spending time and in turn it may also show profit/loss per project.

In general, evolve your process slowly, but continuously. Monitor your problems and the actual costs of some of these problems to encourage yourself to only fix the problems that cost money or morale, not just the problems that are annoying to the bosses.

A tip: implementing any type of metrics in a business can be difficult. Make sure it doesn't come with too big of a stick and set it up in such a way that developers and sales reps are not encouraged to game the data in the same direction. Depending on your business model and each one of their deals, SRs may be prone to push up or push down the number of hours. For developers, their bias will tend to be to show they are busier than they are until somebody points out that they seem less skilled or efficient as their peers.

An added tip: If the metrics aren't going to be used to change people, collect them blindly (so the participants won't know). You will likely get the most accurate information.

Answer 4

Being stuck in a similar situation, I'll let you know our version and how we're scaling up slowly. Generally, as in your case, our PM's manage the developers' time. We've been doing it blindly for a while, but are now using software that allows us to prioritize developer time and display it publicly to everyone in the company. All of our PM's are in the same building, so they are able to converse and decide what the developers need to work on collectively.

This process, however, is still extremely flawed. As you said, morning meetings can change the priority, but generally only if something has gone wrong in a project. I personally feel that a developer PM would solve many issues, but this would potentially help us far more since a few our our developers telecommute. Here is my advice for getting your PM processes under control:

• Document everything! (Estimates, actual time spent, and what each individual is presently working on)
• Use user/developer friendly software for easy collaboration between PM/Devs
• Give the developers a priority queue (I prefer this to having to ask PM's what project needs done next instead of just pressing through the next task)
• Continue analyzing your process and replace areas as necessary

I wish I had more info to give about down the line, but as I said I am about in the same spot - so I'm giving tips to the next level. Of course, outside of small business, this model isn't too plausible, but it is helping us move forward now.