3 ms·
This is an interesting read, mostly because I remember working in the world it was murky and depressing. The unexpected happens, this is an undeniable truth but
by batoure 10y ago
This is an interesting read, mostly because I remember working in the world it was murky and depressing. The unexpected happens, this is an undeniable truth but blowing estimates because of the unexpected should be an edge case and not the norm. There are 3 key thing the team I work with now does to manage the unexpected.
1. Top level commitments should be vague
-the statement "we will build you a website" says nothing about what will be on it
2. Scope the top level commitment, don't over scope, commit only to achievable scope
- If you don't know if something can be done don't commit to it, commit to identifying if it is achievable. Green engineers I have worked with tended to miss deadlines and when we dug into it the problem was often that they took on tasks we didn't even want completed. Commit to delivering something you are certain you can do.
3. Write the scope down, and stick to it.
- A good scoping document is like a good legal contract, it keeps everyone honest while limiting liability. It gives someone a commitment they can hold you to, and it gives you an exit clause if they try to rewrite the rules. If someone tries to change your agreed scope after the fact, adding work means timelines must be adjusted and reducing timelines means work must be removed.
4. If you work somewhere where you can't seem to make 1-3 happen find a new job its just not worth it.
- UK-AL 10y agoThe problem with scoping a project is that no one really knows what's they want at first. Developing software also involves discovering the real user issues by experimentation. If you scope it, you may deliver the project, but you probsbly haven't delivered what they actually needed. The best software is developed with feedback loops.
- bbcbasic 10y agoYes it's no good producing a turd, even though it's an on budget and on time turd.