Industry stats say that less than 1/3 of all projects are completed on time and budget. It doesn't have to be this way. This high failure rate makes a project manager's job one of the most difficult in any industry. Most of the failed projects follow these 6 stages:
- Stage 1: Enthusiasm
- Stage 2: Disillusionment
- Stage 3: Panic and hysteria
- Stage 4: Hunt for the guilty
- Stage 5: Punishment of the innocent
- Stage 6: Reward for the uninvolved
To prevent a project from spiraling out of control, a project manager has to constantly monitor progress, watch out for potential problems, and take corrective measures.
Planning a new project may take anywhere between a few days to a few weeks. But keeping a project on the right track takes at least five times more. This means project managers spend most of their time making sure everything's going right. This is how they do it.
Watching Out for Bottlenecks
The biggest hurdle to how much you can accomplish are the bottlenecks: one or more resources that limit the output of the entire system. For example, if your marketing team can set up a thousand ad campaigns in one day but your creative team can create only a few landing pages, the number of campaigns you can have is limited by the output of your creative team.
If you aren't aware that the creative team is a bottleneck, then a backlog of work will begin to pile up in front of them and you'll have a conflict between departments. Also, the quality of work will suffer because the creatives will start cutting corners so they can clear the backlog; this will, in turn, destroy the conversion rate and render your whole work meaningless.
One way to deal with the problem is to redeploy your existing resources when a backlog becomes too big. For example, the marketing department can jump in and help the creative, or a developer may jump in if there are too many tasks in a QA backlog.
How do you know when someone needs help? By purposely limiting work in progress (WIP). You can prevent work pileups (which results in bottlenecks) by limiting the number of tasks people can work on at one time. It sounds counterintuitive because, after all, you want everyone to constantly work on something and operate under full capacity.
But a large amount of work leads to problems. Developers tend to multitask and work on bugs while they're waiting for QA to complete. This ultimately results in more work for the QA down the road. Work will keep piling up until they end up with an enormous pile of partially-completed work that can't be shipped.
In competitive rowing, a key position is a coxswain — the person in the back of the boat yelling “row, row, row”. He coordinates the activities of all the rowers so they are rowing at the same speed. If one rower outperforms everyone else, the boat gets out of kilter and slows down - meaning, extra power and speed can actually slow the boat down. Same thing on projects. Making one department extra efficient can bury other departments in excess inventory, paperwork, and slowing them down.
It's important to understand that limiting WIP doesn't directly result in more output (because you're still constrained by the bottleneck). Instead, what you get is:
- Better lead time (the time between the task's initiation and completion)
- Constructive frustration which drives improvement. If people complain about not having work, you have a clear signal you need to expedite the process and a justification to ask management/client for more resources.
- Better quality.
Longer lead time leads to poorer quality, as evidenced by the Little’s law. In fact, a six times increase in average lead time results in a greater than 30-fold increase in initial defects. This longer average lead time results directly from greater amounts of work-in-progress. If you want to improve quality, you need to first reduce and then limit WIP.
In ActiveCollab, you can monitor how many tasks are in the In-Progress task list and act accordingly. You can also take a number of assignments a person has as a signal of a bottleneck. When you run the Workload report, it'll show you how many tasks each person is assigned to. If someone has way more than anyone else, reassign some tasks or investigate the matter.
Another way to deal with bottlenecks is to design the team so there are no bottlenecks to begin with. Do this by calculating how many features you need, how many features each role can process, and then hire accordingly.
Let's say you need designers, developers, and testers on a project. An average designer can design 5 features per week, a developer can develop 3, and a tester can test 10. How many people do you need?
After a bit of math, you find out you need: 6 designers, 15 developers, and 3 testers.
This is a pre-optimized system where your only job is to monitor if the people are accomplishing as much as planned. But digital projects can be tough to estimate. Even a concept of what exactly constitutes a feature can be ambiguous.
Pre-optimization at least gives you a starting point. Then, as you work, you'll know what team performs above and below predictions, identify where the bottlenecks are, and staff where needed.
When it comes to software development, beware of the mythical man-month: Adding manpower to a late software project makes it later. This means you should think twice before you hire more developers in order to meet the deadline.
Sometimes you can’t throw more resources at a project. This often happens when:
- a resource is scarce (like developers who knows how to navigate through a client’s legacy system)
- or impossible to increase (like the time you need to get approved by the App store).
In that case, you need to design the system around bottlenecks. For example, if each task has to be run by a senior developer, but you only have one in the team, this makes him the bottleneck. As such, you want to make sure he never runs out of work. After all, an idle junior developer costs less than an idle senior one - especially when they’re the bottlenecks in your team.
When working on a bottleneck, keep in mind that work items vary in size. This means a bottleneck can run out of work simply because there are a few large tasks in the pipeline that are coming too slow, and when they land, the pipeline will get clogged again.
Controlling Quality
When faced with a lot of work, people tend to cut corners intentionally. But sometimes, the quality suffers without anyone noticing it.
For example, a developer may see 100+ console errors when they start working on an app and may subconsciously think “If no one cares about compiler warnings, it means sloppy work is tolerated and I can cut corners in order to get home by 5pm”. When faced with a decision to make something good or to meet the deadline as long as it compiles, they'll always choose the latter because that's all management cares about.
This hurts long-term projects the most. Overlooking one issue leads to overlooking more issues, which snowballs into a tech-debt ridden project that, the longer you work, the more it costs.
You probably heard about the mythical 10x developer who can accomplish 10 times as much as work as an average one. They do exist, but the chance of you having one on your team are next to nothing. If you have a someone who accomplishes way more than anyone else, better investigate. Chances are, you have a tech-debt loan shark.
How to spot tech-debt loan sharks?- They prefer to copy/paste than to spend time on DRY
- As long as it works, how or why is irrelevant
- They care more about finishing a task today than to make next week's task easier to finish
- They don't care how their work affects the overall design
- They don't write tests
- They complain when there’s no documentation but don't bother producing it
It’s easy to lose focus on quality. Project managers spend most of their time thinking about budget and deadlines because they're the most visible and easy to quantify, analyze, and communicate. What gets measured gets done. Non-technical people don't get upset over spaghetti code like developers do - but missing a deadline or going over budget is another matter.
When quality takes a back seat, it hurts your position on a competitive market. In the past, building something took a lot of work so selling was easy. Today, it's the opposite. The market is oversaturated with low-quality work and the trend will become even steeper.
To make sure the quality is good, involve a client from start to finish. They have the largest stake and should approve each major task and decision. But if they care more about the bottom line (and pay accordingly), you don't have any obligations to care about quality. You can't have something fast, good, and cheap at the same time - you can only pick two.
Keep in mind that an app with documented and maintainable code costs 5 times less to develop further so you do have a financial incentive, only the reward is farther away.
Focusing too much on the quality can hurt you. Always do a quick cost/benefit analysis before you ask “can we make this better/faster/stronger”. If it takes a lot of work to make something perfect, but it doesn't make an impact, move on. There are only a finite number of things a team can do, so focus on those that matter the most.
Think of finishing a project like sweeping a floor. You clean most of the dirt fairly quickly, but the last few specks of dust are impossible to remove. So you keep cleaning until you're left with an amount of grime you can live with, put the broom away, and get on with other chores.
Working With People
A project manager's job is to monitor the plan and tell others what to work on and when. If the team risks falling behind schedule, they step in and see what can be done.
A lot of your time as a project manager comes down to managing people. But because you don't have supervisory authority, you have to lead, manage, and inspire people using other methods.
Bad project managers often go through this cycle:
- Ask everyone for status updates
- Be ignored
- Try to attach yourself to the next project so you don't get fired.
Or even worse, they ask a developer for a date to implement something, tell the customer it'll be delivered faster, and complain when a developer misses the deadline. Or they may not even consult with the developer, promise the client something they can’t deliver, sign the contract, celebrate with a big event, and leave the developer with figuring out how to fit a square peg into a round hole.
Another big mistake bad project managers make is measuring success using wrong metrics.
For example, you may notice you complete most of the work as you come closer to the end. This makes your progress chart look like a hockey stick. You think you need a “healthier” progress bar and nicer distribution. So, in order to straighten the hockey stick, you issue an incentive and give a bonus if a task gets closed earlier .
Then people start to pester others to complete the task and the overall productivity plummets because everyone is after their own gain. In the end, your chart becomes a bit more linear and “healthier” - but at what cost?
Same story when you measure work by schedule, quality, and features. You can ship the product on time, with no bugs, and with all the features - but the product will be mediocre because none of the features are that great.
In both cases, you got what you asked for, but not what you needed. Managers make a common mistake of measuring the productivity by counting irrelevant numbers and creating wrong incentives. Then people find a way to hack the system and your incentives end up backfiring.
For example, you can measure the productivity of your tester by the number of bugs they report. They'll be incentivized to discover as many bugs as they can, no matter how small they are; then they'll write a bug report, argue with a developer whether something is really a bug, and waste time.
Measuring a number of completed tasks is also a bad idea. That system doesn't take into the account the person who helps others become more productive and as a result, everyone suffers. The true 10x developer is a person who makes others more productive.
It's been proven that incentives don't help but companies still use them. They’re fine in sales, where the result directly depends on one person; but when you success depends on a team, the result is a collective effort where you can’t easily measure contribution, rewarding individuals is never fair.
Your best option is to drop incentives altogether, focus on keeping good levels of enthusiasm throughout the project, and reward team effort.
Enthusiasm on a project can vary widely, depending on the stage. Everyone is super excited at first, but once you hit the first roadblock, it’ll take some of the wind out of your sails. You’ll push through, only to reach a roadblock so big that you'll start to question whether you should continue at all.
Your job is to motivate people to keep working when the team starts to have second thoughts. Each time the enthusiasm drops, keep in mind the enthusiasm curve. Once you understand how your team is going to feel, you can prepare accordingly.
Also, keep in mind the 90/90 rule of software development:
The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time.
Staying on Top of Projects
The three most important questions you need to have answers to at any time are:
- Who's stuck?
- Who's too busy?
- Who's idle?
There are several ways you can get the answers to the questions above.
You can organize a status meeting, but meetings are generally a bad idea. A “quick” 1-hour meeting with 6 participants takes up 7 work-hours (taking into account one hour due to context switching). If the goal of the meeting is for you to get a status update, find a better way.
Daily standup meetings are popular because they are shorter and concise. They can be useful if you don't have any structure and need a place to start. But they aren't always useful as you can skip some days without noticing; plus, keeping them short takes a lot of policing, which can be bad for morale.
The best solution for getting status updates is to encourage the team to update their tasks as they work. It's a chore, but it’s an even bigger chore when someone needs information or help, and has to pull someone aside to get it. If tasks are updated regularly, you can catch up with what's been happening by going through a particular project's activity stream, instead of asking people what happened or having them send a report.
Each of the three questions from Scrum daily standups can be answered using ActiveCollab without having the meeting:
- What did I accomplish yesterday? Check the person's activity stream.
- What will I do today? Check the Team Timeline or run the Tasks report.
- What obstacles are impeding my progress? Encourage the team to use @mention in comments, instantly message or talk to the person if it's urgent, or consult with the project manager.
Reports are a project manager's best friend but they require a lot of work. When you see a burndown velocity chart, it seems so easy to make - but it’s not. The creation of that nice chart took a lot of badgering. It’s simple: if you don't feed the right information into the system, you won't get a useful chart - which is the whole point of having it in the first place.
Reports operate under the principle "garbage in, garbage out". If your team member doesn't bother putting estimates or track time, your reports will be worthless.
The best way to get people to enter admin data is by enforcing a default rule. For example, when a bug is reported, it needs to be in a standard format or else you won't take it into account. Same way, each task should have an estimate and a label before it can be put in the backlog. If a task doesn't have time logs, it can't be completed.
At first, you'll have to check each task to make sure it follows the procedure; but after a while, you won't have to. If you refrain yourself from feeding your team a fish (in this case, updating tasks for them), but teach them how to fish (update tasks themselves), you'll be much more productive as a whole.
When you have good data, you get good reports. With ActiveCollab reports, you can find out the answers to a lot of important questions:
- What's overdue? Run the Tasks report
- What's coming up? Run the Tasks report
- Who's too busy and who's idle? Check the Team Timeline report
- What's someone up to? Check a user activity from the People section
- What's new? Check a project’s activity and the Global Activity
- Who has too many tasks? Run the Workload report
You can even get an answer to highly specific queries like: What are all the bugs related to feature X that the client reported last month but haven't been yet been completed? Just run the Tasks report and you'll find out. You can even save the query as a preset report that you can get to at any time when you need an update.
In addition to activity on the project, you can keep track of time and budget and get answers to the following questions:
- How much of the project has been spent and where? Run the Project Budget vs Cost report
- How much time has someone tracked? Run the Time Tracking report
- How good are our estimates? Run the Estimated vs. Tracked Time report
Once you have the answer, you can correct the situation. For example, if some tasks take longer than expected, you can break them down into subtasks. If you see that you burned more of the budget than you planned, you can talk with the client about it.
This is another good reason to invite clients to ActiveCollab. There, they can see for themselves where the budget went, item by item. This level of transparency instills client confidence and makes them want to hire you again because they know they can trust you.
What to Do When Life Happens
Things change. No matter how well you defined the project scope or planned your project, something won't go as planned. This is your chance to revisit the initial plan and talk to the client about updating the statement of work.
When something threatens to derail your project, you can be:
- optimistic and try to push your team to finish the project on time,
- or you can be realistic and make the plan fit the new circumstances.
When planning, know that a plan will need adjustments as you work and discover new things. Don't get attached to the plan so much that you are reluctant to change it or pivot. This is your opportunity to make the plan better.
For example, you might plan to end up in point Z in 2 months; but along the way, you're likely to visit points A and B during the projects. You may even end up somewhere beyond point Z.
Nothing is set in stone and it's ok to change the plan, even pivot, as long as you communicate with the client and they agree.
That's why it's good to make buffer zones in the plan: the periods when you can reassess where you are and update the plan. This often happens after research and after creating a high-fidelity design.
Having frequent milestones also help you keep things on the right track, especially with larger projects. If you only have long-term, high-level milestones, you won't have the chance to realize something is wrong until it's too late. Milestones give you a chance to reflect and discover issues before they become too dangerous.
Often, half way through the project, someone will tell you that meeting a deadline is impossible because of a bunch of things. If you involved your client and invited them to ActiveCollab, they'll be aware of the issue and you'll face the problem together.
When project requirements (date, budget, or features) change, there will be paperwork. You have to discuss the course of action with the client and add an addendum to your statement of work.
There are several ways to know when you won't make the deadline:
- The most obvious one is that someone will tell you, or at least warn you ahead of time.
- Another way to see if you'll miss the deadline is by reviewing the timeline on a weekly basis. This is where the Project Timeline report in ActiveCollab comes in handy. You have all your projects in one place and you see what tasks are late (red) and due soon (orange). Then you can open late tasks and leave a comment, asking for status update.
You can also run the Estimated or Tracked Time report to see what tasks take longer than expected. This information can be also obtained in the Tasks report and Team Timeline.
When reviewing deadlines, keep in mind that the project deadline doesn't matter. The only deadline that matters is the next one because it affects every other deadline. If you miss the design deadline, you can’t meet the development deadline, and ultimately the launch date.
A cool trick is to think about deadlines as time-limited challenges. This way, you don’t panic and approach the whole thing from a positive perspective.
What to do when you realize that you’re aren’t going to meet the deadline? You can:
- Move the deadline
- Increase the budget and hire contractors
- Reduce scope of project
No matter what action you choose, you have to work it out and negotiate with the client.
Sometimes, the client will change project scope at the last minute but insist on the same timeline. If you defined the project scope and made clear the terms of your engagement in a contract, this won’t happen. That is why it's important to always have a written trace of what was approved and when. If you can point to what the client said in an email or a comment in ActiveCollab, you'll have an easier time negotiating.
Your team can also cause scope creep (scope creep is introducing new elements into the project that might overwhelm available resources). This happens when a team member is so enthusiastic about the project that they want to make it perfect so they work on more that what’s agreed upon. The problem is, the original plan doesn’t account for the extra work and something more important can get pushed.