We have all been there. Working in projects can sometimes be frustrating. Hardly because of the exciting content, but oh my…the administration, the meetings, the reporting, the art of gathering the steering committee. Only to discuss recycled issues, growing backlogs and team responsibilities. Having a project manager explaining what’s already explained in the attachments.
Sure, we have tools and methods to help us out. Prince2, Agile, Lean; certainly useful done right. But people will be people. I’m not the first person to acknowledge that following procedure leads to planned desired outcome, to be deviating later on from that same procedure because of, let’s say, changing circumstances. When in fact I just want to bypass some annoying procedural thing. We’re not robots — yet?- and that’s a good thing. Bending the rules is human nature to foster flexibility and creativity otherwise locked up in our structured “blue” project approach. Nevertheless, products are to be delivered, targets to be reached and deadlines to be met.
I was thinking about this when working with a client in commercial real estate development. They are deploying blockchain as a means to manage the building development lifecycle, starting as early as the design phase. Facing a constrained project budget I managed to bend the wish of putting “everything in the blockchain”, towards a focus on a few but direct issues in the building phase. I suddenly realised this is what we mostly do, consciously or not, when we are constrained: downplaying, filtering, focusing on the bare minimum to get the job done. How can we leverage this human fallback scenario as a ‘feature’ in building projects where constraints are default? But first a tiny explainer on permissioned blockchains.
I guess most of us know about public blockchains like Bitcoin and Ethereum. Everybody can join them. Permissioned blockchains on the other hand are private in a sense that a consortium of organisations run a distributed administration on behalf of themselves. Consortium members set out the governance, smart contracts and the like, according to the stakes they hold. Open source permissioned blockchain platform Monax has some excellent info on this stuff.
At this stage, a permissioned blockchain design fits our requirements quite well. We’re setting up a consortium/stakeholder group of developer, project manager, contractor and subcontractor. Issues are experienced in statements of work on scope, budget, deadlines and deliverables. Sounds familiar, right? We agree to only register transactions at legally binding moments and drop all other possibly interesting facts for blockchain entry. These transactions correspond with the execution of ordinary legal contracts, drawn up by the participating members of the blockchain. For instance, when work is approved and delivered, a contractor may transact an invoice, which in turn shall be approved by the project manager or the developer, in order to trigger another transaction or payment.
Given that we only register at legally binding moments, we achieve the bare minimum of complying with building project execution rules set out by the consortium beforehand. We could have chosen to put in more, but then we would likely be heading for administration fatigue. Now, stakeholders have a clear and evenly distributed incentive to register these facts on-chain: either you won’t get what you ordered or you won’t get paid. Besides, you get your standard blockchain goodies of ‘who did what when’, an audit trail to refer to when things get messy. Meanwhile, our stakeholders spend more time discussing creative design and building method options, freed from the burden of project overhead. Having a project manager communicating innovative ideas instead of repeating what’s already distributed on-chain.
Being constrained challenges us to keep things simple. Rewards are obvious: manageable project scope, fewer mistakes and unambiguous communication. Blockchain is new and hard to understand for outsiders, consultants have to focus on minimal achievable targets delivering immediate results to gain confidence, with less project overhead as a bonus. As we are progressing I’m wondering if we can keep it this way. When concepts are proven we like to load it with bells and whistles, not realising we have to maintain these later on. Let’s see how this works out for my client. I’m curious to find out if we can stay on track.
Do you suffer from project administration fatigue? How did you handle your frustration? I would love to learn from your experience.