How construction project management boosted our software execution
The case for learning from traditional industries
What does software product delivery have to do with Manufacturing or Visual arts?
Well, they are all in the business of creation. And therefore, they all share a high-level fundamental process of taking a vague idea and turning it into reality.
We call it the Fundamental Creation Flow, and as product managers, we are essentially doing one thing — moving ideas through the Fundamental Creation Flow.
It doesn’t matter what your product is and how your team is structured.
You start with a vague need that needs a solution, you push it one step forward to become a schematic solution and one more to become a detailed solution. And then you harness all your energies and team members to move one more step toward execution and make it a reality.
You are literally pushing up an idea through the creation cycle.
And it's not just you. Everyone who gets up in the morning and attempts to create a reality in this world goes through the same high-level fundamental cycle. Architects, Writers, Artists, Construction contractors, Manufacturers, etc.
As product managers, we can, and should, learn from creators in other industries. They encounter similar problems and solve them in wildly different ways from us.
What we learned
Can we leverage construction methodologies to solve the most effort-intensive part of the creation cycle — Execution? Can we plan more confidently and manage the execution with fewer communication breakdowns?
We decided to try.
At Autodesk, we build software for construction professionals.
While conducting research for our Schedule tool, the product we built from scratch and released a few months ago, we were exposed to many techniques that innovative construction companies use to plan and execute some of the biggest projects humanity is building.
It made us think.
Construction entrepreneurs need to balance end-user needs alongside time-to-market and execution costs continually. Just like us.
Construction site managers have dozens of subcontractors to keep synced and sequenced while making sure they can provide clarity on when things will be completed. Just like we need to manage three teams working on the same feature.
Construction projects keep changing even when construction is underway and have numerous dependencies and clarifications that need to be resolved to make them tick. Just like every feature we ever built.
We methodically embedded three construction management techniques based on lean construction methodology. We tweaked them a bit and polished them so they will work for software development.
We packed them into an easy-to-embed framework that we call SWORD™.
Its stands for — Syncs; WORk planning; Decision log
And if parts of it sound like something you’re already doing, that’s great. But the real value lies with all of these parts working together to build a clear, collaborative execution engine.
The results were clear from day one. We dramatically improved our ability to plan and track complex projects while minimizing open-ended questions to literally zero.
Developers on our team report that they have more confidence in the processes and feel much more ownership over what they build.
We call that a success.
So, what is SWORD™ all about?
Let’s get to the details.
Work planning :
Work planning is a collaborative process that creates more accurate, efficient, and, most importantly — higher team commitment to plans. It is also an artifact that allows full transparency and readability of the execution for all stakeholders.
Before every feature or initiative, we have a dedicated work planning meeting. All relevant stakeholders are there. Developers who build the feature, Designers, Products, QA, and others that we feel have experience building similar initiatives.
It's not a kickoff meeting. We actually hold it after the kickoff, and everyone is already familiar with the feature. It is pure planning.
We all have a tendency towards under-planning. This meeting, with everyone onboard, ensures you and your team take enough time to plan.
The meeting has two parts,
1. Work breakdown
Each stakeholder with actionable tasks in this feature breakdown his work into tickets. Each ticket gets a working day estimation. Overall guidance is that if a ticket is more than five working days, it should be broken down into two. This is the only noncollaborative part of the process.
2. Timing
One by one, each team member places their tickets on the timeline. It sounds simple, but this is where the magic happens.
The First developer places his tickets, and it usually goes like this:
- BE Dev: puts his tickets on the timeline.
- Tech lead — “I actually think you should do X before Y. I did something similar a few months ago.
- Other BE Dev — “and there’s no way you’ll finish Z in 4 days. It’s at least 7 days work”
That's nice. We just got our BE plan better and more accurate, but that's not all. Because now all other developers place their tickets as well
FE Dev: puts her tickets on the timeline
BE Dev: “You can’t do this; you won’t have the API ready before I finish that ticket”
QA: “ I think we better build this BE part before because then when we finish this FE ticket I have a QAable chunk” ( he puts QA ticket in place)
The same happens with Designers and Products. Crucial dependencies are revealed, times are communicated and reviewed, and the overall sequence of execution is crystallized a few times and with the people that matter.
All parts of the work are planted in the right places with everyone’s agreement and understanding.
At the end of the meeting, we have an understandable, collaborative plan committed by the whole team. We pin it to our Slack channels and revisit it regularly (more on that in the Sync part of SWORD)
There is no ideal place to handle work planning (yet). We use both Mural and some Construction-specific work planning software. The important thing is to allow color-coding by person and arrange rows by areas of work or vice versa.
(small work planning in Mural. Color-coded by team members. Important milestones that might affect all of the execution are marked with green checkboxes)
(parts of a large work plan in construction work planning software. Color-coded by team members and arranged by area of work )
Decision log:
It doesn’t really matter how good you are in moving vague ideas into a concrete PRD. Once execution begins, you will have a bunch of things coming in from Devs, designers, and QAs that will need clear decisions.
Don’t try to fight it by creating more detailed PRDs. You can’t. This is just the way reality works. Taking an idea into a schematic solution (high-level requirements and design wireframes for most of us Products) and then into a detailed Solution (detailed PRD document and design specs) is a process of narrowing it down through decisions. The execution phase isn’t any different. You will need to keep getting those in a tight team context, where everyone must be aligned, and decisions must be clear and discoverable.
I used to lose items I should’ve decided on and would find out about them minutes before production. I used to decide things, communicate them in slack, and find out the opposite found its way into the code. Something wasn’t working.
Our team came up with the Decision Log. A freestyle interpretation of the Construction projects Constraints Log.
Decision Log is a collaborative table we handle per feature. Everyone has access to it and has the right to add items that need a decision. We try to keep the term “decisions” pretty loose to allow team members to add deliverables that block them or a design that needs a second look.
Once a decision is made, it is documented, and its status changes from “To Decide” to “Decided and not synced”. Once requirements are updated, the design is tweaked, and the team is aligned, we change the status into “Decided and synced”
Very lightweight. Very efficient.
Personally, I also use it to document marketing decisions and high-level value proposition thoughts. This allows all team members to see all aspects of the emerging feature.
I also have a filtered view with only open decisions I need to make across all features. For the first time in my career, I can open my day with a clear view of all the decisions I need to make. No multi-channel slack browsing, no going through the list of developers in my mind and thinking about what I owe to whom. Clear, collaborative, transparent decision log.
Syncs
We all do syncs. But they are not always that efficient. With Workplan and Decision log built into your process the syncs will get a new flavor and will become the place where everything gets connected.
In our team, the feature owner — the developer who is responsible for making the feature happen, is the one who runs the syncs. And it has a very clear structure.
(1) Go over the decision log — what’s open? What’s been recently decided but hasn’t been communicated? What’s the priority of the decisions? This part makes sure everyone is aligned on the information.
(2)Go over the workplan — where are we? What is the next milestone? Who should get involved next? If needed- edits are made, and tasks are moved around to ensure the work plan reflects reality.
Bottom line
We have been working according to the SWORD framework for almost a year. Every feature we kickoff gets its own Workplan, its own Decision Log and dedicated syncs. With all its parts combined, we feel that this new framework provides unrivaled clarity and efficiency.
Acknowledgments
The creation of SWORD framework is a joint effort of Nitzan Sankevitz ; Einav Kivshany and myself. It was piloted, polished and fully adopted by the amazing Schedule team in Autodesk (Odiya Erlichster ; Liron Zluf ; Dor Tchizik ; Vipul Singh ; Gilad Green and Sagi Yemini)
