I have had my PMP certification for about 10 years now. One of the fundamentals is a pledge of allegiance of the triple constraint, that Schedule, Cost and Quality are your three constraints that need to be managed.
We are further told that if the client/project sponsor holds onto 2 of those controls then the 3rd one is the domain of the project manager (and the team). This is based on an assumption that scope is all determined before ground is broken on the project. I think that this is a fall-back to the construction industry’s view of projects. Of course everything is planned out before you lay the foundation.
The reality though is that scope is never fixed. Functionality is always added in and removed because the sponsor/business leader frequently holds onto time, money and functionality.
Question: So what is the developer to do ? They are told that they need to have this done, by that time and at x cost (this message is delivered by the project manager who is themselves constrained).
Answer: The developers holds onto quality, and they will (mostly) passively resist you controlling that that too. How do they do that ? By throwing the first thing that works over the fence and moving onto the next deliverable. This is not a character flaw, this is their only response to unreasonable constraints.
What actually happens is that if you are going to push a team to do the impossible they are either going to fail, or they are going to deliver exactly what you asked for (and there is a fairly good chance you haven’t defined quality for this deliverable). We can go on and on about what defines quality, but in software terms, good developers know quality when they see it. Typically it is somewhere between “fit for purpose” (does it do what it is supposed to do and no more/less) and “compliance with standards”.
So how do we ensure quality ?
- We learn to listen to the developers when they say they can’t do this in the time allotted and the resources supplied. This is hard. Sometimes we push back on them and sometimes we negotiate functionality with both the developers and the clients but our business teams have learned to respect their judgement.
- Code reviews on a regular basis inspire the best in programmers. What’s more is that team development (especially at a conceptual level) ensures quality is designed-in.
- I have found that you rarely get a complete developer who is a lone ranger. The interaction of the pragmatist (who is inclined to get it done) and the idealist (who would like to turn every function they have written into a coffee table book) makes for a healthy development effort. Neither approach is wrong and neither is right and part of the business interaction is helping make informed decisions.
Back to the Triple constraint. So what would I suggest ?
- Certainly define quality for business critical systems. The more discreet those specifications are the easier they are to test against. They then become part of the functionality part of the triangle.
- Become evangelists for automated testing. Again this exposes code quality to the light of day.
- Finally, Listen to your teams and work with developers you trust. I’m all for pushing back on assumptions and potential hedging but if I become too inflexible I know what’s going to happen …
“Deploy with confidence”
Author
