In rugby, progress is made down the field by the person with the ball going as far as possible before handing it over to someone else on the team, who will take it a bit further before handing it off to someone else until, hopefully, someone crosses the line and touches down for a try. Given the severity of tackles in the modern game, a player is lucky to unload the ball to a teammate before being brought to earth by an opponent. After the tackle, it is unlikely that the player will care much either way until the effects of the impact wear off.

On this page:

• Involving Stakeholders in Design Decisions
• Addressing Maintenance and Troubleshooting Needs
• Catering to End Users and User Interface Design
• Summary

Involving Stakeholders in Design Decisions

Similarly in project management, we are inclined to put everything into crossing the finish line and then stop, gasping for air. What we often neglect is what happens after our project is finished. What happened to the deliverables we so painstakingly produced? In the greater scheme of things, how did the project contribute the organisation’s grand plan?

Addressing Maintenance and Troubleshooting Needs

Considering your deliverables across their entire lifecycle will make life a lot easier for the people involved down the line. Are we producing something that needs to be manufactured? Will it need maintenance at some stage? Will an end user have to learn how to use the thing? These questions need to be asked at the very start, in what Project Management Professionals (PMPs)^® call the initiating process group, specifically the Identify Stakeholders process.

In development projects, too many project managers acquire tunnel vision and focus their efforts on delivering on the project’s requirements and not considering the consequences of design decisions down the line. However, identifying those who will take over our products or services can provide valuable insights into how the project can provide added benefits down the line.

Catering to End Users and User Interface Design

Having the project’s design engineers visit the factory floor can be an eye-opening experience. Some of their cleverest creations could be the most difficult (and most expensive) to make. Simple changes could make the product much cheaper to produce. Listening to the people who will make the product and involving them in the requirements planning stage of the project makes a great deal of sense.

Similarly, another group of project stakeholders are the people who will maintain the product. How can their troubleshooting and repair operations be facilitated? What sort of documentation would allow a software maintainer track down bugs? How should the main service items in an engine bay be located for easy access?

Finally, what should be an obvious group of stakeholders are the end users. Surely, our project deliverables need to cater for them? Sadly, this is often forgotten about. Computer support personnel often try to surpass each other with tales of operator errors and their amazing stupidity.

However, when you look at these “stupid” users, in many cases you can see where they are coming from. For instance, a common problem for early CD player users was putting the disc in upside down. Well, when you put a record on a record player you put the part you want to play on top! Similarly, the famous woman who put a stray cat in the microwave turned out to have a farming background, where premature lambs were put in the oven to revive them.

Summary

Of course talking to end users might be difficult. Your project could involve creating a breakthrough product or service that needs to be shrouded in secrecy. Even so, finding potential end users within the organization should be possible and they will be of great help to the project’s user interface designers. The Japanese developed a technique they call poka-yoke. This is idiot proofing. We see this in plug design where there is only one possible way to plug it into the socket. We can also adapt poka-yoke principles in data-entry applications. For instance, if you ask for the year of a date first, that will tell you if it is a leap-year. Then if you ask for the month that will tell you how many days are in the month, so there should not be any 31st of February mistakes.

Velopi’s project management training courses cover Project Stakeholder Management. If this area is intriguing for you, you might consider one of our project management certification courses that are held online in our virtual classroom. Find out more by visiting our training page or by contacting us directly.