This document discusses lessons learned from project management examples that went wrong due to unclear requirements and lack of stakeholder involvement. It emphasizes the importance of defining measurable requirements, understanding industry context, involving stakeholders in decisions, and having a requirements change process. Two case studies are presented: one where the customer was heavily involved and the project went well, and another where the customer was not as engaged and disagreed with the final product. Key lessons include having the proper contract type, not defining low-level requirements or features in contracts, and documenting all requirement and design decisions for traceability. Early symptoms that a project may go wrong are also outlined.

1. Project management by
example
Learning to respect the requirements, from projects
that went wrong

2. Agenda
● Requirements and stakeholders
● Requirements, contracts, and customers
● Summary
● Q&A

3. Requirements and stakeholders

4. A set of early requirements
● Able to carry people and essentials
● Four-cornered power
● Fast
● Safe
● Able to handle mixed terrain

5. What the team built
Photo by Lucho Renolfi on Unsplash

6. What the customer wanted
Photo by Sergio Rota on Unsplash

7. Or... what the customer wanted
Photo by Adam Jang on Unsplash

8. Lessons learned: what did we miss?
● Measurability
○ The camel is faster than a person walking - what was the baseline?
● Industry context / assumptions
● Deciding on the architecture too soon
● Stakeholders not involved in enough decisions and meetings

9. Requirements, contracts, and customers

10. An agile story
Small team: project manager, two developers, QA, design
Customer
● Agile
● Regularly joined daily scrum calls
● Attended sprint ceremonies in person
● Heavy emphasis on cost-benefit analysis
We changed direction frequently
Customer and us happy with the product and the result

11. A pseudo-agile story
The same small team
Customer
● Agile
● Mostly joined daily scrum calls
● Rarely attended sprint ceremonies
● Heavy emphasis on function
We changed direction frequently
After 8 months, we thought the product was finished

12. The customer disagreed
We believed it was a time and materials contract (they usually were)
We believed the requirements were agile: agreed in sprint planning meetings
When we declared complete, the customer pointed out
● Contract was fixed price
● Original requirements described in the contract had not been met
The contract had been set up by the business development (sales) team
● Optimistic
● Ambitious

13. Lessons learned - customer requirements
Do not agree to fixed price contracts - if possible
Do not write features or low level requirements into the contract - if possible
If you inherit a contract
● Read it
If you have fixed requirements
● Say “no” a lot
● Have a requirements change process

14. Lessons learned - requirement changes
Changes, discussions, and agreements made in meetings or on calls may be
forgotten
● Write down decisions
● Circulate the decisions (or minutes) for approval
● When you update a requirement (or other) document, make sure the version
history is visible and auditable
● Make sure the customer representative has the authority to approve and sign
off requirement changes

15. Summary

16. What can go wrong
If the requirements are unclear, or the contract is unusual, or the stakeholder(s)
are not engaged, typically:
● The team work together happily but build the wrong thing OR
● The team spend a lot of time arguing about interpretation of requirements
● Impact on team’s morale
Your awareness of what might go wrong can help you explain to a stakeholder
why they need to engage

17. How can you predict problems early?
Early symptoms that a project might not go well
● Sprint ceremonies are missing key people
○ Stakeholders
○ Developers
○ Designers
○ You do not know what you do not know
● Sprint ceremonies or scrums do not produce value
○ Team members do not contribute
○ Or the team talk a lot, but revisit old debates and do not come to conclusions
○ The team are scared to raise important issues and problems

18. How can you predict problems early?
More early symptoms that a project might not go well
● Requirement sizings are large
○ If a story has a large story point or time sizing, this is a symptom that it is not well understood
● Code reviews / signoff are slow
○ Symptom of team lead overload
○ Symptom of lack of respect between team members
● Solution architecture is fixed too early and by one person
○ The solution needs to fit the requirements
○ If solution architected before requirements understood, future requirements will be bent to fit

19. Q&A

20. About us
We built fflow to improve resource planning and operational efficiency for projects
and teams
● visualise availability and assign projects in a combined scheduler
● manage HR absences
● track (billable) time
● reporting by time and by task
Find out more at https://fflow.io/