What can your project do for me?
Why do projects fail? Project managers revisit this question every now and again in a moment of introspection and it’s hard to argue with the answer offered by Henry Cho, UX practitioner: “Projects fail when they fail users.”
Last week I went to an information session on a new UX course, which is the tech nickname for ‘user experience’. While presenter Henry Cho focused on explaining what UX is and how it could be used, it occurred to me that a lot of what he said correlated with the requirements definition phase of project management.
One interesting diagram depicted a number of design attributes—usable, useful, desirable, findable, credible and accessible—all feeding into a word at the core: value. As with any project outcome, a design needs to have all of these traits before it has any value for the end user. You and I both know this. We see it every day in some of the brainless concepts marketers come up with because it seems cool but actually has no real value. Things like automatic status updates declaring you the ‘mayor’ of a cafe when you ‘check in’. Who cares?
Cho, the UX practitioner leading the course, said that UX was not just about ‘usability’ but about the requirements that would form the user’s ‘story’. For me, this was akin to reminding us that in project management it is not just about the ‘iron triangle’ of meeting time, cost and scope constraints with a project output, but meeting the true needs of the customer. At the same time, it was also realising that a customer’s ‘story’ went beyond focusing on end user need and also encompassed the idea that we need to make sure it also focused on making sure the customer also wants what we deliver.
This requires a greater amount of user empathy than most project managers are used to. After all, this kind of strategising tends to happen when the project is mapped out, which is generally before the sponsor assigns a project manager. (And I’d wager that just as many projects fail because sponsors don’t think to empathise with the user either.) Interestingly, the people best equipped to understand users are change managers, but they are rarely brought in early enough in the project where they can have the best effect.
I have no neat takeaway lesson from what I observed, but I can offer you something to chew on when you next consider your end user stakeholders: given value is in the eye of the beholder, if a tree falls in the forest when no one is around, does your project still have benefits?
