Q: We Have Grown From One Project To Many Projects, How To Manage?

Written by Sean Murphy. Posted in 5 Scaling Up Stage, skmurphy

Three keys to making the transition from a one project startup to scaling up with many projects: keep a list of all projects, finished, active, unstarted and contemplated; maintain a status page that is the single source of truth for where the project it; conduct, document, and act on post-project assessment findings.

Q: We Have Grown from One Project to Many Projects, How to Manage?

Q: Our startup has a successful first product and is now hard at work on many projects to support and improve it, as well as launch other products. I am an early employee brought on while we were finishing and launching the first product. Deadlines were tight and we all felt a lot of pressure but for the most part priorities were clear and everyone knew what was going on because the entire startup was in one project meeting, twelve people piled into a conference room.

Now we are at twice that size running a number of projects but priorities are much less clear and no one seems to have the full picture. One founder is focused on improving the current product, another is really the key sales guy selling our first product, while the CTO is focused on a new product that she feels is what our customers really need and will obsolete our current product. Any practical advice you can offer on how to get a clear picture of the current status and priorities?

managing many projects can make your vision narrow and start to blurA: It’s a strange sensation to be in a smoothly running race car for several laps and the suddenly feel the car start to vibrate, pull in for a pit stop and watch the pit crew get into a fist fight over what is going wrong while other cars you were ahead of start to lap you.

With one project in a small team you can keep everyone on the same page and minimize priority conflicts with relative ease (not that anything is easy in an early stage startup).  When you move to multiple projects with different timelines and different teams that may have some overlapping membership things get much much harder.  There are a variety of reasons for it, the principal ones are:

  • Leaders don’t actually anticipate the need for more communication, coordination, and collaboration efforts as the team grows above two dozen or so. Things have been going so smoothly and so much has been accomplished it’s hard to anticipate the phase change that occurs when the company is no longer small enough to have a productive problem-solving meeting together.
  • Multiple projects means internal competition for resources where trade-offs can no longer be made against a single overriding goal.  It’s still one company and calculating cost of delay, for example, can be useful. But the reality is that people start to identify with the project team more than the entire firm.
  • You cannot just work harder, there is too much to do and more behind what’s in front of you. You have to do less, to avoid burnout because you are now clearly in a marathon not a sprint, and have to do the right things next because you cannot do everything.

I have been through this transition a few times and it’s always painful.

Three key starting points: list of projects, status page for each project, post project assessment

Here are three places to start that are critical to bringing clarity:

  • List of active projects with who is on the team (if nothing else, this at least tells you who to ask for more info)
  • Status page for each project, even if it’s just taking an email and posting it so there is a “single source of truth” about where it is
  • Post project assessments / retrospectives be conducted on completed projects (even some that are a month or two old) and notes put into the status page for the project

Is there a list of projects?

There needs to be a map of efforts and what’s been committed for each project:

  • who is on the project team: are there any open positions or missing expertise
  • short description of task, objective, key goals
  • target delivery date
  • key identified risks or unknowns — what does team need to learn in order to succeed
  • identify any critical equipment or other resource dependencies

This list will get much longer over time, if you can at least make a list that has a project name, description, and team members you can then continue to refine and elaborate over time.

Each project should keep minutes or status from any meetings or conversations

It’s helpful if there is a status page for each project that shows the team’s current working consensus on issues, risks, and current delivery or completion date. It can be emailed out but it’s also very useful if there is a web page that is guaranteed to be the best info on the project without having to call a team meeting. If there is a team meeting scheduled (and there should always be a next meeting scheduled until project completed and after-action (post-project analysis / retrospective has been done) so if people want to come they can.

It’s often better to get every project listed with a few key pieces of information and then keep improving your understanding that get a lot of information from half or even a majority but have some missing completely from the list. It’s also useful to put down projects that have been deferred or are scheduled to start in 3 to 6 months, just so the priority is clear to everyone that “we are not working on that until….”

I am a huge fan of wikis for this purpose–I make a exception for SharePoint which is more of an abomination–because they natural keep a revision history and allow project members to edit/update easily. Start simply and don’t let status become trapped in email

There should be a retrospective or after action for each project

At the end of each project, or at major milestones for large projects that may take more than six months, it’s very important to identify:

  • what has gone well you can build on or that other projects should adopt,
  • what has gone poorly that you should avoid doing next time–even unintentionally, this is where checklists come in handy–and,
  • what experiments or new methods or approaches you should consider for a new project that is similar.

The key to getting better is recognizing your mistakes and not have more than one or two projects make the same mistake, much less a team making the same mistake on the next project. Equally important is to recognize what made you successful–root cause analysis is as useful for success as it is for failure–so that you explicitly incorporate those approaches into other projects that can benefit.

Related Blog Posts

Trackback from your site.

Leave a comment

Quick Links

Bootstrappers Breakfast Link Startup Stages Clients In the News Upcoming Events Office Hours Button Newsletter SignUp