Needs vs. Wants
/I was catching up recently with a friend about our days and were discussing communication with clients, expectations and requirements.
Both of us had had long days, and their story went something like this.
They had been helping a client complete a transaction, had confirmed the details and and then proceeded. The client reviewed the end result and then said "that's not what I expected". Classic problem, sometimes things are not understood the same by everyone.
In my friends case other people had to get involved and everything was sorted out. Those who got involved reversed course and ended up in a place the client was happy with.
Sound familiar?
I often work with clients during the start of a project defining requirements and when dealing with potential change of requirements during a project.
The difference between we want and we need in a project can be a large chasm.
When someone asks "Why aren't we doing it this way?" you need to be able to answer and speak to how the current approach meets the requirements.
When someone new joins the project or stakeholders change you need to be able to communicate the boundaries of the project and the implied scope.
So how do you properly manage changing expectations in a project setting?
That's where documented and agreed requirements, constraints, assumptions and risks come into play. When change requests come you need to be able to help the client understand the potential impact and then manage it. Change is going to happen, but what counts is how you manage it.
What can make this easier?
Lots of healthy discussion and understanding of the changing client requirements is always a great start, but the following are a list of things that may help throughout the project and specifically can be useful when dealing with changing requirements.
1. Overview presentation
Create an overview presentation. I like to have one for the project kickoff meeting. It lists the objectives, and outlines the components of the project and the requirements from the entire team - most importantly it defines what is in scope and what is not.
This information is usually available in a Project Charter or a Statement of Work.
This is handy if someone joins the team later, for a mid-project refresher, or as a quick reference you can provide to someone if they have a question.
When questions of change come up its time to review the original objectives and then talk about it with everyone having the same (refreshed) information.
2. Whiteboard with the stakeholders
I often find it useful to use the whiteboard and list out all the details: options to meet the new requirement, impact to the current plan, pro and con of the items, and risk including probability. Work this through with the team and stakeholders.
Great way to get buy in and collaborate.
Try to facilitate more than lead the discussion, let the team get to a result of at least two options that will meet the requirements and stay within your constraints.
Include the estimated effort, budget changes and timeline impact for options. Budget and time will usually heavily influence the weight of an option and whether a want is approved to become a need.
3. Avoid snap decisions, don't be afraid to have the team 'think on it'.
Having the team take an important item away and come back prepared to discuss in more detail is important.
Not everyone engages the same way. Some people (myself included) prefer to spend time thinking something through and then discussing it.
If you can take another 24 hours, try not to force people too far out of their comfort zone, they may need more time to come up with questions and form their thoughts in order to participate. It is usually worth the day investment.
Set a deadline for when the discussion will happen. This ensures it will happen, and that the expectations are set. Depends on the group, but a day is a good starting point.
4. 'Show' the change if possible.
If you can display things visually in a diagram, that can be helpful; some people are visual and will be more engaged if they can 'see' what the changes mean.
Diagrams can make the difference in getting across a concept and keeping it whole in a dispersed team.
Diagrams may make it easier to demonstrate options or possible impacts on the solution and design.
Diagrams don't always have to be complicated or highly detailed - conceptual or logical diagrams can often help demonstrate the difference between current and options on future state.
5. Everyone has a chance to comment
Clear communication is key to success here and so is the requirement for people to feel involved and buy in.
Most people will accept a decision contrary to their own if they have an opportunity to be heard.
Give them the chance so it doesn't become a roadblock and prevent everyone from buying in.
6. Document the Decision - Use a Decision Record!
When you reach a consensus or decision, document it! Email is fine in smaller less structured projects, but some will require decision documents and supporting information for the project sponsor. Time passes and memory fades… so document.
Don't forget to update your deliverables and all project artifacts; sometimes a change flows through a lot of things.
Few things are more annoying and confusing after a project is transitioned to operations than an implementation document that doesn't align with the design.
The decision record and project change request are your friends and IMHO the best vehicles to keep track of approvals during projects. They don't only have to be used for changes in budget! They can also be used to keep your scope accurate and ensure you are measuring your success against what was agreed upon.
Every client, project, team and situation is different. Use what makes sense and keeps things moving, but always document so you can measure success.
Things change in projects (as in life), hopefully some of the above will help your project team be more successful.
Thanks for reading.
Cheers,
James
:)