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?
A: 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
- “Now What? Your Post Launch Growth Plan” Podcast and Transcript
At a company level, what’s the challenge after launch? The challenge is that you have to build an effort that you can sustain and scale, which means you have to develop things like process and metrics and dashboards.
So…process, metrics, and dashboards…most of you probably have left big companies where you had process dashboards and metrics, and you are thinking “I don’t want any more of that.”
Just as little process as possible is a good thing, but you can’t get away from it completely.
- 8 Tactics For Entrepreneurs From “The Pragmatic Programmer”
One key tactic stressed is documentation. My take: as important as “rough consensus and running code” is clear documentation of plans, assumptions, problems fixed, approaches considered and rejected. Anticipate the needs of people who have not yet joined the team who will need to understand how things work and why. I am not proposing a “cover your ass” approach as an accepted common source of truth for decisions and the effects and outcomes they were expected to produce. - Record to Remember, Pause to Reflect
- Five Questions to Ask Yourself Twice a Year
- Use Wikis for Team Projects
- Lunch & Learn: Using Wikis for Projects
- Ten Tips for Leveraging Blogs and Wikis in Your Consulting Practice