8

I've seen many organisations where project managers would reason like this:

We specialise in very small projects. Since a very small project needs a very small team, I should allocate one person or two to each project. However, this means that only a couple of people in the organisation know about the project; if they leave or are struck by a bus, the project is doomed. Therefore I will allocate four or five people to the project just in case, despite the unnecessary overload.

I can understand that a project manager may be concerned about an employee quitting and leaving the project unmanned; that would be disastrous. However, compensating by making four or five people work on a very small project that only needs one or two doesn't look like a good idea.

What other strategies can you think of to minimise the risk while preserving resources?

|improve this question
6

Good, clear documentation like the project's goals, the tasks involved, the risks, the schedule and record of communications with the client.

|improve this answer
  • 1
    +1 Thanks, Mark. The documentation approach is a good one, but then again, it can be argued that very small projects need to pack light regarding documentation. Otherwise you will need as much effort to document what you do as to actually do it. Is this the only way forward? – CesarGon Feb 11 '11 at 22:48
  • If minimizing the risk is paramount, you MUST either have more people or documenting... you can´t have your cake and eat it too. – Kwang Mark Eleven Feb 13 '11 at 4:03
  • 1
    @CesarGon - you don't need to go overkill on the documentation, just enough to ensure continuity. @Kwang Mark Eleven, right on. Its a matter of finding the balance. – Mark Phillips♦ Feb 14 '11 at 1:05
  • @Kwang: you are right; I am accepting this answer because I think that a good balance between documentation and people is the key. Thank you. – CesarGon Feb 14 '11 at 1:06
3

Changing resources shouldn't doom a project as long as it's well documented and you have smart people working in your organization. It's also helpful if the previous people working on the project were smart and organized so that the code is readable and maintainable. Although there will always be a learning curve, other developers should be able to step in and fill the role.

I've worked with developers that have stepped in and filled a role on a project, and after a few weeks they were productively engaged in the project. I have never seen a project die because someone left the organization.

|improve this answer
  • Thanks, but this is too software-oriented. Anything more general? – CesarGon Feb 12 '11 at 23:03
  • 1
    As long as things are well-documented and follow industry standards, it shouldn't matter that much. In the military, for example, I had many commanders and senior NCO's come and go, and our unit kept running smoothly. I've also worked with people who filled more of a project management role in customer service, communicating with a large client, and that change didn't negatively affect the project either. – jmort253 Feb 12 '11 at 23:41
3

One thing is that fear of overtaking a project from a person "hit by the bus" is overrated. Actually I've seen many cases where, for whatever reasons, teams had to do this and it wasn't that hard.

Having said that everyone prefers to be prepared. I'm not sure that throwing more people on tiny projects is the solution. I think it's more about organizing the work in a way which helps to share the knowledge among the team members then just allocating them to the project.

A few ideas which come to my mind.

  • Pair programming (if we discuss software project). It's not an easy thing as people often resist this technique but this isn't something completely novel or unknown. People are pairing for long time and in specific environments it seems to work very well. And you can have at least twice as many people who know the project.

  • Collective code ownership (again for software projects). It works especially well for projects in maintenance phase. If you have a bug to fix or a change to apply you can get any free person to do this, even if they aren't familiar with the code. If they get lost they can ask for help those who worked on an application earlier. After some time you have knowledge about projects spread all over the team. The same technique you can use against projects in their building phase but you need some kind of tech lead or project lead anyway to coordinate everyone's effort.

  • Maintenance team which overtakes responsibility for the project after some phase. It makes a project transition to maintenance phase explicit, thus enforces sharing knowledge, some minimal reasonable documentation etc.

|improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.