How do your run internal projects at your consultancy?

Question

Hello,

I work for a consultancy whose main revenue stream is from client work. We also run projects internally e.g. to implement a CRM system for our sales team.

We build release plans for internal projects just as we do for client projects, though resources are often removed from internal projects when required for client work. In short this can lead to stop-start projects, and/or overruns in time.

1. How do you run projects internally?
2. How do you ensure internal projects get the respect required, whilst allowing resources to switch to client work?
3. How do you keep internal projects as accountable for time/budget as client projects?

I look forward to hearing your ideas!

Jonny

Answer 1

We once had a (really stupid) company rule that stated: customer projects are always served first. Then the billing system stopped working. Was kind of funny seeing people getting a little surprised when the developer maintaining the billing system said: "Sorry, can't come in to fix it, I am in a customer project for the next two months."

Since then internal projects are handled exactly like the customer projects and if the needs of the two projects collide someone has to make the decision which project wins. And yes most of the time it is the customer project. And yes again: this leads to stop and go projects, but that is just the way it is.

The countermeasure I try to implement is to have the internal projects set up especially carefully, ensuring that a different developer can pick up the work with minimal friction. This means:

• a central starting point to identify all documentation and resources need to get started
• lean but complete documentation
• almost dogmatic use of an issue tracking system (Jira being my personal favorite)
• frequent buildable commits
• frequent codereviews
• fully automatically build and deployment
• high test coverage
• continuous integration
• everything under version control

This way internal projects can also work as training grounds for new developers.

Do I need to say that although I try to achieve this, it is not easy, because it means a lot of coaching? Especially in the beginning of a project with unexperienced developers. But I am convinced that it is the right thing to do, and most colleagues agree.

Answer 2

I recognize this situation even though I'm not at a consultancy. We have several long-term projects where the resources are often yanked to take care of crises in short-term projects. It's common to work on a project for a few days, be pulled out for eight weeks, then you go back for a few days again.

I think your question of "how to ensure internal resources get the respect required" sounds like "how do I give my project higher priority". But in any company you have to accept that there are low-priority projects; the interesting question IMHO is how to create a sane work environment where you keep yourself and others motivated, and where the overhead of the start-stop mode is kept to a minimum.

So far what I've been trying to push for is that once you do go back to a project, you get to work on it for at least a week. The exact size of the period could be adjusted to the project, but the point is that you should have time to start on some item and finish it within the period, so that you get closure.

The other (or one other) issue that needs to be solved is helping people remember what they were doing the last time they were on the project. I haven't tried this yet, but I think it would help with a software tool or wiki for maintaining a distributed to-do list, to keep fairly detailed notes of where you are in the project and what you are doing. Not only can this help the original developer get back on track, but it also makes it easier for other developers to continue where he left off.

Answer 3

The shoe maker's children have no shoes.

It seems the natural way to solve this is to remove the distinction from internal projects and client projects. To that end, create a contract from the department needing the service with the department producing the service. It'll cost the same anyway (maybe a little more for overhead), but it is a way of showing the value you are adding to the company (otherwise the upper-ups will see it as just something to do when you aren't making money).

Of course before you start in internal project, you should do the same things an external client would/should be doing. Do a cost-benefit analysis, look for off the shelf solutions, etc.