In all the projects I've worked in my life there has been one single success factor: the knowledge chain is never broken.
Executing a project requires the contribution of different domains:
- Commercial: what are we trying to sell, what are the key selling points, what is the business model.
- Operational: how are going to render the service.
- Functional architecture: how are we going to split the functionalities in different components.
- Coding: how are we going to translate everything into code.
- User experience: how are we going to layout the interface, what flow do we want the customer to experience.
- Legal: how will we reflect the service in a contract.
- Risk: what math model will we build to control and manage the risk.
- Human resources: how many people do we need to provide the service, what type of profiles should they have, where will we hire them.
I haven't even started yet, but I guess you get the point.
In order for a project to be executed, all those pieces interact at some point in time to provide their input. An unbroken knowledge chain means that all those interactions happen directly, physically. I mean there is real human connection happening there. I'll try to illustrate what does work:
A project requires 4 guys: a graphic designer, a coder, a product designer and someone from customer support. They all gather in the same room to discuss, eventually each one will go and produce some stuff.
This is the startup model, where scarcity of resources makes it easy for all the knowledge bearers to sit down together in a room. Other methodologies like the famous agile try to replicate the startup formula in more structured environments.
What does NOT work: someone sits down on its own for 10 hours to produce a requirements document 70 pages long. This document is sent to a project manager. She then distributes this doc to the functional architecture team to translate this doc into another 140 pages doc. This last doc is sent to another team, off site, that takes what is written there and translates that into code...
This last model breaks the knowledge chain. There are silos where no human interaction happen between the people that know what to do. It just does not work. We keep on hitting our heads against this wall because it makes sense conceptually: proper definitions on proper documents, it should be possible and it is better, everything is documented and we don't have to rely on people, but on word documents. But it doesn't. It just doesn't work.
What COULD work: the 70 pages doc is sent to a project manager that, before distribution, reads it. Every single question is discussed, personally, between the user and the project manager, until the knowledge is dumped not so much on a piece of paper but on the project manager. Only then the project manager sends this forward to get a 140 pages doc back, which she then reads and tries to understand in depth before forwarding it, grabbing a good share of technical knowledge. And so on...
In this model there is a superhero that, on top of the heavy corporate methodology, assumes the titanic task of not breaking the knowledge chain by consolidating all the knowledge herself. All projects in a corporate environment that worked followed this same pattern because it is the only way in such environment to keep the knowledge flowing humanly through the components of the project.
If you face a new project, just think: what domains and skills are required to make it happen. Then think: how am I going to make sure that those building blocks are arranged so that there is a human flow of knowledge between them. And good luck with it.
Enjoy the weekend. Cheers!