Petter, Stacie: Managing user expectations on software projects – Lessons from the trenches; in: International Journal of Project Mangement, in press (2008).
doi:10.1016/j.ijproman.2008.05.014
Petter interviewed 12 project management professionals on managing the end-user expectations. What worked and what did not work?
The conclusions cover three broad areas – end user involvement, leadership, and trust. As far as user involvement is concerned the practices that work included
- Listening to users
- Asking questions
- Understanding concerns about change and actively ease these
- Working with the user (not at or to them)
- Let user make tough choices, e.g., on functionality, budget, cost, time
- Create small user groups to hear them all
- Giving credit to specific users for ideas
- Keep users involved and updated throughout the project
What did not work were – not communicating the project status, and trying to outlast difficult users.
On the leadership dimension useful practices mentioned include
- Ensure project champion
- Articulate clear vision
- Motivate team to get it done
- Educate users on benefits
- Obtain buy-in from primary stakeholders
Factors leading to end-user dissatisfaction were
- Scope creep
- No mission
- No explanation of purpose/value of the system
- Follow others
Trust building activities that worked well, were sharing good and bad news, and providing specific times for deliverables. What did not work were hiding the true status of the project, and ‚fake it until you make it‘ also known as hiding knowledge gaps.
[…] Original Alex […]
Is the user involvement during the whole project (Agile) or just in the requirements phase?
In Software Projects, whether you’re using Agile or not, the best way is to properly gather requirements and ask all the possible questions (if you don’t ask, the client won’t answer). Software Projects are always risky because the clients typically don’t know exactly what they want.
I have an excellent document about The Technical Requirements Specification (TRS) in Web Projects. I think it greatly relates to your article.
Still, going Agile is probably the best way in Software Projects.
Well, I am a big follower of continuous QfD for RuP/agile project developments. While I do see that smaller projects can easily live by a good prototyping approach, not much is gained if you do large scale projects (ERPs, core business systems).
Personally I think the best approach is to have mixed demand-supply side teams, at least for the specification part.
If that is done properly, call it super-user and IT business analyst, this can be a fruitful collaboration mode. Which of course manages user expectations almost automatically, throughout the entire lifecycle of the project.