One time my wife and I took a train from NYC to Montreal. I think it was supposed to be a 9 hour trip.
It was okay until we got to the Canadian border... and then we sat there for 3 hours while they checked everyone's passports.
Being stuck sucks.
Let's talk about projects.
The worst feeling is watching time waste away with nothing getting finished and having no idea what is going on. Your project flew along smoothly for weeks and then suddenly came screeching to a halt.
Here are 6 things that can cause your project to slam on the brakes and what to do about them.
1. Reaching for the stars instead of the next rung on the ladder
Engineers love to be engineers. We'd much rather (try to) build a spaceship than (actually build) a birdhouse.
Here is a practical example:
Last week one of my team members and I were building an email notification system for one of our products. We needed to offer a setting that lets people control how often they receive emails.
One option was to build a completely customizable system that lets them choose all sorts of settings like how many emails they receive over how many hours, days, or weeks, etc.
The other option was to offer three simple settings like this:
I'd like to receive notifications a) Immediately b) Once per day (summary) c) Never.
We went with the second option.
Will we meet every single possible need? NO! And that's a good thing. Our interface is simpler, we saved a ton of time, and we've covered the most common use cases.
The first thing I learned in engineering school was KISS - Keep It Simple Stupid.
Solution: Lead with design.
Putting design first helps you catch these types of decisions before a line of code is written. Whether it's pencil and paper or Adobe Illustrator, mistakes are much cheaper to fix than after they are written in code.
When you have visual and textual descriptions of what a thing is meant to do, it's harder to veer off of the path. However, for this to work, you have to go into the design process looking for these types of decisions.
Design isn't just making things look nice - it's a critical part of deciding what to build.
2. Segmenting work based entirely on required skill
Every company I've ever worked with has tried to do this. It's logical. You create big piles of work labeled as design stage, front-end, back-end, etc.
This can work out OK in some situations - mostly early in a project - but as your projects (and teams) grow, it will lead to enormous headaches. If you have hundreds of tickets floating around categorized like this, three things will happen:
1. Prioritization and cooridination will become a nightmare.
2. A lot will be happening, but you will feel as though nothing is ever truly finished.
3. You will end up with a back-log a mile long.
Because work is being done haphazardly. When you have a small set of todo items and a small number of people, this is not obvious. If I have one person on my team, and I'm only focused on a few features right now, it doesn't really matter how I organize it.
When your projects and teams grow, this feels like chaos. A level of choreography is required that was not before.
Solution: Divide work based on orthogonal product capabilities.
In a nutshell, this means that you should look at what parts of your product can function independently from one another, and create buckets of todos around those. From there, you can priorotize what to tackle first.
People will still work on things that fall into their skillset, but the process is centered around completing entire "capabilities" as opposed to individual tickets.
As an example, one of our current projects involves doctors uploading documents to patient files. Instead of splitting this into all the various parts and mixing todo items in with all of our other work, we have a Basecamp list specifically for this feature. It makes it very easy from a project management persepective to check the status of things, look through conversations and completed items, and generally know where we stand.
Simply put - things are well organized and not scattered.
3. Your problems are too big
If the first thing I learned in engineering school was KISS, the second thing was that you have to split big problems into smaller ones.
Tasks that have a scope that is too broad invite problems.
Imagine that you tell me, "Go build me a house." I have a lot of desicions to make.
On the other hand, if you ask me to build a cabinet, we can address a dramatically smaller number of questions, and I can go get it done.
Solution: Put a time limit on todo items. If it won't fit, break it up more.
Right now our team is testing a four hour time limit. I picked that because it means we all get updated a couple of times a day.
This doesn't mean that we start a stop watch - and when four hours is up you're done. It's just a ballpark thing.
This is as much art as it is science. It's very difficult to know ahead of time how long a technical task will take unless you've done the exact thing before in the exact context. It's more of a guideline than a rule.
If you are non-technical, this is going to feel like it is very much out of your hands. That's where feedback loops come in.
4. You have a weak feedback loop
The points in #2 and #3 fall apart if your team communication sucks. I can organize my project to perfection, but if noone ever comments or checks off items - or if they wait for days to do it - I'm still in a bad spot.
Solution: Create a feedback policy.
For our team, if an item starts to bump up against our time box, one of three things needs to happen:
1. The ticket gets completed.
2. An explanation of why the ticket isn't completed gets posted, and we figure out how to either finish it or break it into pieces that are more manageable.
3. An explanation of why the ticket isn't completed gets posted, and we extend the deadline a bit if it can't be split.
This isn't about micromanaging people. It's about keeping a fluid conversation going in a project, and it's about making sure that everyone has the information that they need to do their job. I can't plan out our next phase if I don't have a rough idea of when our current items will be completed.
5. Not having a well-defined pipeline
This is related to other points, but takes a look at a different aspect of the problem.
In the early days of a project, you often don't have a big team with a diverse skill set. If you're lucky, you have one or two people who can handle a lot of different things - design, development, planning, etc.
As your project grows and you add more specialized team members, proper sequencing becomes critical. For example, if you hand a back-end engineer a todo item that's too vague or too broad, you will end up waiting a long time for a result that may or may not be what you wanted (aslo see #3).
Solution: You need a sequence of people who prepare work for the person after them in the sequence - a pipeline.
This doesn't have to be complicated with a lot of people involved.
On our team, we have a couple people who talk to clients, work out what is important to build, and map out the first round of categories and todo items.
From there, if design is needed to clarify the idea, a designer will grab the todo and add the minimum amount of design needed.
Finally, the todo gets picked up by developers and completed.
An immediate benefit of designing a pipeline like this is that you can easily spot bottlenecks. If your team never has enough to do, then the first part of the pipeline (work generation) is too weak. If there are tons of designs sitting around waiting to be developed, your development team needs more resources (or possibly focus).
When you have no pipeline or system like this, it can be very difficult to tell where things are going wrong.
6. Bad code
Many developers have the skills to get projects up and running, but they run into trouble the larger a project grows.
A project is never as simple as it is at the beginning, so some amount of slow-down is normal. However, with proper development techniques in place, it should be minimal.
If you feel like you are on the blue line, you may have a problem.
Solution: Optimize your pipeline first. If your developers are clearly the bottleneck, add more resources or change developers.
It's tempting to reach for this point first when you feel like a project is going slowly, but it's also the hardest to verify when you are non-technical. How can you even know for sure?
Development tends to be a magical, black box to non-technical people. If you have done all of the other things right, you will at least have a transparent pipeline that lets you see exactly where todos are getting stuck. Again, this is just as much art as it is science.
Developing a new product is a difficult proccess. Feeling like things are not moving forward is incredibly frustrating and can leave you feeling powerless.
If you follow the suggestions listed here, you will be able to identify when and where things are going wrong, have conversations with the right people about the right things, and have a sense of control about the progress of the project.
Do you need help organizing a project?
Leave your name and email below, and we'd be happy to chat with you.