Project Tools and Techniques
Everything up to here has been about deciding: what to build, by when, with whom. This chapter is about the instruments you use to actually run it — and the surprising fact that most of them are the same information, sorted differently.
In short
- Timeline, board and backlog are one dataset, three orderings — by date, by state, by priority.
- Each answers a different question. Reading the wrong view for your question is the most common source of project arguments.
- Different roles belong in different views. A sponsor reading a board sees activity and infers progress.
- The tool is not the method. Buying software does not decide how you will work; chapter 5.4 does.
Why the same work needs more than one view
A running project generates one question per person per day, and they are not the same question. The sponsor wants to know whether the launch date still holds. The engineer wants to know what to pick up next. The person who requested the work wants to know why their thing has not started.
Those three questions cannot be answered well from a single screen, because each requires the work sorted a different way. Sort by date and you can see whether the deadline survives, but not that four items are jammed in review. Sort by state and the jam is obvious, but the deadline is invisible. Sort by priority and you can see what is coming, but nothing about whether it is on track.
What tooling problems actually look like
Almost no project fails because it picked the wrong software. What goes wrong is subtler, and it shows up as friction rather than as a tooling complaint:
- Status meetings where two people describe the same project differently — and both are right. One is reading the board, one is reading the timeline. Nobody realises they are answering different questions.
- Stakeholders who feel out of the loop despite constant updates. They are being sent card-level detail when what they need is milestones. Detail is not the same as visibility.
- Engineers asked to update three places. If the timeline, the board and the report are separate artefacts rather than views over the same records, someone is maintaining the difference by hand — and it will drift.
- A plan that looks fine right up until it doesn't. Usually a team running only a board: excellent for flow, blind to whether the end date still holds.
- Work that arrives by direct message and never appears anywhere. The tool then describes a project that does not exist.
Every one of these is a mismatch between a question and a view — or between a view and reality. That is why this chapter starts with the three views and only reaches software at the end.
How many of them do you actually need?
Running all three is not automatically better. Each view you maintain is a thing that can go stale, and a stale view is worse than an absent one because people keep trusting it.
- Hard external deadline, dependencies between people? You need the timeline. Without it, you will discover the slip too late to respond.
- More than three or four people, or work that queues between them? You need the board. It is the only view that shows a bottleneck.
- More requests than capacity, and someone has to choose? You need the backlog. Without it, priority gets decided informally by whoever asks loudest.
A two-person project with no dependencies needs a list, not three views. A regulated programme with fixed dates and six teams needs all three and probably a fourth report on top. Match the instrumentation to the actual complexity, and revisit it when the project changes shape.
Tool decisions come after method decisions
One ordering matters more than most teams expect: decide how you will work before deciding what you will work in. Whether the project is iterative or sequential determines which views matter, which in turn determines which features you should care about in a product. Teams that buy first and choose a method afterwards tend to inherit whichever way of working the tool defaults to.
What this chapter covers
Using Gantt Charts
The timeline view: bars, dependencies, milestones and the today line — and why the arrows matter more than the bars.
Read 5.1 →Kanban Boards
The flow view: columns, work-in-progress limits, and how to read a bottleneck off a board before anyone reports it.
Read 5.2 →Managing a Backlog
The priority view: ordering rather than grouping, refinement, and deciding what is genuinely ready to start.
Read 5.3 →Agile vs Waterfall
The method decision that sits underneath all three views — and the hybrid most real teams end up running.
Read 5.4 →Task Management Tools
Only now the software: how to judge a tool against how your team already works, rather than against a feature list.
Read 5.5 →How this looks in AB
In AB Project Management the Gantt, Kanban and Backlog views are literally three renderings of the same task records — not three artefacts to keep in sync. Change a due date and the timeline moves; drag a card and the status changes; reorder the backlog and the queue the team pulls from changes. Because nothing is duplicated, no view can quietly go stale relative to another, which removes the most common cause of the mismatches described above. Everyone can watch the view that answers their own question and still be looking at the same project.
Terms used on this page
Every term below is defined at more length in the full project management glossary.
- Gantt chart
- A horizontal bar chart of the schedule — tasks down the left, dates across the top. The timeline view. More →
- Kanban
- A flow method where work crosses a board of columns, each capped by a work-in-progress limit. The state view. More →
- Backlog
- An ordered list of everything the team could do, most important first. The priority view. More →
- Milestone
- A zero-duration marker for a significant point. The right altitude for a sponsor, where card-level detail is not. More →
- Critical path
- The longest chain of dependent tasks. Visible on a timeline, invisible on a board — which is exactly why teams running only a board get surprised. More →
- WIP limit
- A cap on how many items may sit in one column at once. The mechanism that turns a board from a picture into a method. More →
- Agile / Waterfall
- Iterative versus sequential ways of running a project. The method decision that determines which views matter. More →
Related reading
What goes into the views
Scope, schedule, resources and risk — the plan these tools render.
3.0 Planning Basics →Using them week to week
Monitoring deliverables, handling change, and reporting to people outside the team.
6.0 Tracking Progress →Who needs which view
Designing the information flow so each audience gets what it can act on.
4.3 Communication Planning →