Processes are tedious as hell, but if you don’t set them up, you'll waste time, miss deadlines, go over budget, infuriate your clients, and never work again.
Thankfully, most digital projects don't require elaborate processes.
Modern VS Classical Project Management
Project management is an old profession. How else would Egyptians build pyramids if there wasn’t someone to organize the processes and manage workers.
But project management wasn’t a scientific discipline until the 1950s. It was then that people started writing books on how to organize projects and systematically develop and apply techniques. Those books focused on really complex projects, like building a self-navigating missile system or an electrical power plant - not something you can do in a month or even a year.
So most techniques and frameworks you learn at universities and business schools are really complex. We're talking about PRINCE2, CPM, PERT, CPM, etc. They are not for you. They fail when it comes to digital projects, like building a website or an app or running a marketing campaign.
Why aren’t they suited for you? Because digital products are malleable: they can easily be changed, adjusted, and improved.
For example, once you've built a bridge, that's it. You can't go back, refactor, improve incrementally, fix a bug, or pivot and change everything. You need to plan everything out upfront because the cost of a do-over is higher than the cost of the project itself.
Redesigning a website or rewriting an app from scratch also costs, but not as much as tearing down a bridge and rebuilding it.
Plus, code and design are never truly finished. We need to update and improve websites and apps every day just to keep up with the latest technology or a change in business.
So we're more lax about digital. Just look at the way we name design files or our Git commit messages - even our “final version” goes through several “final” revisions.
How Agile Helps Team Deal With Digital Projects
To sum up: big, mission-critical projects need big, complex frameworks. Digital projects on the other hand only need a few principles and a tool or two.
The principles that are better suited for digital projects, as summarized long ago (2001) in the Agile Manifesto, are:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
Pay special attention to the "over" part. It basically says:
“Don't bother planning, something's gonna change anyway. The best thing you can do is listen to your client/users, see how they use the product, and iterate until they're satisfied.”
That's all there is to agile. Experts and consultants sell trademarked methodologies they developed (like SCRUM, SAFe, RAD, RUP, etc.), riffing on the same principles. But they are overkill for smaller companies, plus their complexity goes against the core agility tenants.
All agile methodologies presuppose that projects change. Some give you general pointers on what you should aim to (Lean), some give you concrete tools (Kanban), and some are all-encompassing prescriptions for the entire workflow (Scrum).
Lean is agile taken to the extreme. It advocates delivering a working product as fast as you can and then work based on feedback. "Fail fast" is a common advice for startups that best embody the lean spirit.
For example: if a client asks for a website, you don't do user research, plan a sitemap, or spend hours crafting perfect copy - it all takes so much time! No, you just put one call-to-action for visitors, launch it, and see how it performs.
Then, you see how people interact with the page and what they need. You can use heat maps, put a chatbox so they can ask you a question, or test it on a few users. Based on that, you can see what’s missing. As you gain insight, you start adding more elements based on the feedback.
Everything in Lean revolves around Minimum Viable Product (MVP) and eliminating waste. If some activity could be bypassed or the result could be achieved without it, it’s a waste: paperwork, processes, managerial overhead, switching between tasks, waiting, extra features, abandoned code, testing edge cases - who needs those?
Lean is not perfect. It’s great when you're dealing with a lot of uncertainties and want to test the idea before you spend more money. If the client has an idea for an app but has no clue whether someone will actually use it, Lean is perfect. They can test the market fast and not lose money if it's a dud.
But if a client hires you to redesign their website, you don't need lean. You need slow, methodical research so you can make the most efficient website. Or if you’re developing an app, it needs documentation, extensive interaction, research, and testing.
Unlike Lean, which is more of a philosophy, Kanban is a concrete tool you can use. It’s a board that helps you visualize parallel processes.
In Kanban, you write what needs to be done on a card and put it in a To-Do column on a board. When you start working, you move the card to another column. When you put all your tasks on a board, you can easily get an overview of the whole project.
Kanban is great for spotting bottlenecks on your projects because of its visual nature. You can see how many tasks you're currently working on and where you need to devote more time and resources so you can get more things done.
The most popular framework for software development is Scrum. Most organizations that use it have big projects and need the robustness, even if it comes at a price.
Scrum prescribes how everything about a project should function: how to organize a team, communicate, choose and estimate work, and track progress.
Here are the basic steps of a typical Scrum workflow:
- Interview your client and write user stories (tasks) based on what they need.
- Put those stories on a Kanban-like board in a backlog and assign points based on how much resources a story will need
- Decide what stories you'll work on for the next version of the product
- Try to finish what you've said you'd do
- See how efficient you were on a nice burndown chart
Scrum isn't the most efficient use of your resources, but it's standardized so it's easy to implement, most developers who are new on a team are familiar with it, and management doesn't have to think.
It's like cooking a dish by following a recipe instead of coming up with the best possible dish using resources you have in your pantry. It's not the best solution - just the most convenient.