One of my favorite wester movies is The Good, The Bad and the Ugly. Throughout the movie, the two main characters, Tuco (played by Eli Wallach) and Blondie (Clint Eastwood) dispense words of advice in the form “There are two kinds of people in this world…”
The last exchange takes place in a large cemetery just before the end of the movie. Blondie says to Tuco, “You see, in this world there’s two kinds of people, my friend: Those with loaded guns and those who dig. You dig.”
To paraphrase Blondie, in this world, there are two kinds of development projects: those that are technology refreshes and those that are brand new systems.
The New and the Refreshed
A brand-new system is just that – something new. Behind the new system may be a totally new set of business requirements or a mix of old and new requirements. The key to a new system is that’s it’s a “clean slate”. Everything the system delivers will be brand new (or mostly brand new) and a new experience for your users. Probably the best thing about working on a new system is that there isn’t much to compare it against because your users have never seen a system quite like it.
A “technology refresh” is a new system designed to replace an older, legacy system. Usually, the reason for replacing the legacy system is because it hasn’t kept up with changes in technology. For example, my Dentist had an integrated system for managing his practice that was based on Windows 95. Fifteen years later, he was using the same system. He ended up selling part of his practice to a company that furnished a new “dental practice management system” running under Windows 10 as part of the deal.
Most of us who have worked on technology refreshes know that these projects are more than a “refresh”. For example, I worked with a legacy system that was built using a 1990s era Computer Aided Software Engineering (CASE) tool. Originally, the tool generated code that ran under Microsoft Windows using the old client/server paradigm. The system came out just as the world was moving to web-based, N-tired applications delivered to the user through a web browser.
Fortunately, the CASE tool vendor came out with a new version that generated Java code (you could say that it was a refresh of the development tool – which is was). Because of Java, the old system could now run under Windows or Linux through a web browser.
Voilá! A technology refresh!
But things were not quite as they seemed. While the new version of the CASE tool generated Java code, the resulting web pages of the “refreshed system” were pretty darn ugly. They didn’t have the same look and feel as the MS Windows “heavy client” front-end of the legacy system.
Another issue that in a world obsessed with mouse clicks (as the users of this system were), the “refreshed” system required more mouse clicks to do the same tasks as the legacy system. Beyond that, the first version of the technology refresh, from a user perspective, was more like a “re-skinning” with the new skin not looking quite like the old skin because of the differences between a native Windows application and one delivered through a web browser.
Shifting to Autopilot
I wasn’t around when the system described above went from a client/server/Windows architecture to a semi-modern web architecture. I do know that there was some angst in the transition, but the population of end users wasn’t that large at the time of the refresh.
Fast forward five years later when the number of organizations and people using the system grew substantially. Instead of a hundred or so users, several thousand spread across the country used the system. Lots of people had prolonged exposure and experience with the system. Some of these users had become “superusers”. They know where the kinks are and they know how to get around them to make the system function better for them.
After delivering the web version of the system, things settled down. Developers moved on to different projects and the crew that managed the projects for developing and refreshing the system scattered to the winds – some retiring, others moving on to other positions. The organization cut the budget supporting the system along with the staff that wasn’t replaced.
Perhaps more importantly, the relationships between the team that developed the system and the stakeholders was allowed to wither. The big requirements meetings, the change control board meetings, even the process used to collect software problem reports and enhancement requests scaled back. There was no formal user group and communications between the users and the team supporting the system. What did pass as communications was sporadic. Stakeholder management had gone on autopilot.
Refreshing Stakeholder Governance
Sooner or later your system is going to need a refresh. Along with the system refresh, you should look at how you are managing your stakeholders and evaluate if that needs to be refreshed, too.
In the example I gave above, the stakeholders were not being actively managed. There were no defined stakeholder governance processes and structures. When the next technology refresh requirement reared its head, the stakeholders and the organization responsible for the refresh weren’t ready for it. It became very difficult to manage user expectations about what the new, “refreshed” system would deliver. This, obviously, is not a good situation to be in.
The governance that I’m discussing here is not the same as the governance used to manage your enterprise information technology investments usually overseen by a “C” level executive (like the Chief Information Officer, or CIO). Rather, this governance is at the stakeholder level.
While it’s true that the CIO and the executives sitting on an Information Technology (IT) investment review committee are stakeholders, I’m talking “grassroots”, down in the weeds stakeholders – the kind directly affected by the systems delivered by your team. Our discussion here deals with establishing a governance structure involving your end users. And you should think of your end users as being your customers.
Defining Your Customers
Let’s say that you’re responsible for delivering a point of sales terminal system to a department store chain. Who are your customers? Are your customers people coming in from off the streets to make purchases? Or are they the store employees responsible for operating the point of sales system and handling the sales transactions?
I would say that, in this example, the store employees are your customers. Sure, the public plays a very important (even critical) role in the sales transaction. They’re affected by how well (or poorly) the system functions, but they don’t actually use the system. I bet if you asked a random, off the street customer what their requirements are for a point of sales system, they would say that they want it to get the right change – if they say anything at all. That doesn’t help much with requirements for the point of sales system.
For example, when I worked for the federal judiciary on the Financial Accounting System for Tomorrow (FAS4T) system, the sponsoring organization was the Accounting and Financial Systems Division of the Administrative Office of the U.S. Courts (AOUSC). However, the vast majority of FAS4T users worked in the over 100 U.S. District, Bankruptcy, and Circuit Courts around the country. My Division Director sponsored the FAS4T project and funding came from his budget. But the users of the system didn’t report to him-they reported to the managers of the various court units.
You might think that every court unit is exactly alike, but that’s not the case. There are differences in organizational structure, and different units have different purposes (pretrial/probation versus public defender, for example), which accounts for the differences in the ways that each accomplishes their work. That’s why it’s a good idea to involve a cross-section of the stakeholders in the project. If you focus on the Public Defenders and ignore the Clerk’s office, you’ll probably end up with a system that nicely supports some Public Defender offices while ticking-off the Clerk’s offices.
Stakeholder Governance and Representative Democracy
The ancient Athenians had true democracy – every free man (slaves and women excluded) had a say in what the government of Athens did. There was no senate or house; everybody had a vote, which were taken in large assemblies. For example, let’s say that a prominent Athenian thought it would be a good idea to sack a city in Persian held territory to improve the Athenian financial situation. An assembly would be called and the freeman would vote on whether to approve the operation.
For really big projects, your end user population could easily approach that of ancient Athens. It’s simply impossible to get everyone involved. You need a representative form of governance to reach out to your stakeholders and get them involved. The members of your governance bodies become “force multipliers” and help to disseminate messages designed by the project team and to process feedback from the stakeholders.
Finding a Sponsor
During times of war, the ancient Athenians appointed a “strategos” who led the war effort. Similarly, for your project, you’ll need a strategos in the modern form of a project sponsor. The project sponsor should have enough formal and informal authority necessary to influence stakeholders that may not be in the sponsor’s chain of command. Without it, they’re fighting a losing battle and it’s very likely that the project will fail (if it manages to get off the ground at all).
Ideally, the project sponsor should be as high up the chain of command as possible. This is not to say that the CEO has to be the sponsor of every project. You need to analyze your stakeholders and then identify the optimum management level to have as the sponsor. If you have someone too far up for the size and scope of the project, they could become easily distracted by other, broader priorities to the detriment of the project.
I’ve been in the unfortunate situation where the project I managed supported an entire federal agency, but the sponsor wasn’t high enough in the organization, so he didn’t have enough clout to move the project forward. He couldn’t talk to the executives in the other program offices (all of whom outranked him) and convince them that his project deserved some of their attention. If the stakeholders are not under your management’s control and their involvement is needed for project success, then your project sponsor’s inability to make the project a priority with stakeholder management is a huge risk.
I’ve also been very fortunate to work on a project that had a very engaged and active project sponsor. He was a high-ranking official respected across the entire enterprise (an enterprise made up of enterprises). His bosses made it very clear that the project was a national priority. He didn’t have any trouble convincing his contemporaries that his project was one of their priorities. In short, your sponsor can make or break the project and everything associated with it. Like planets, good sponsors are hard to find, but they’re out there.
The sponsor is not a member of your project team, but the organizational “owner” of the project and whatever the project team ends up delivering. As the project manager, you help the sponsor by keeping them up to date with project plans, accomplishments, and risks/issues. In some situations, you’re going to need their help to clear up an issue that’s impeding progress.
For example, you might need something done by another organization, but they have other priorities that are holding you up. Perhaps a call from the sponsor to that organization’s executive might get the ball rolling? Don’t hesitate to ask – that’s one of the main jobs of a sponsor – to use their formal authority and get things moving.
The Steering Committee – Helping the Sponsor
For big projects involving lots of geographically dispersed stakeholders, your sponsor needs help in sponsoring the project. That’s where the steering committee comes in. Ideally, the steering committee should consist of not more than seven executives or managers at a level comparable to the sponsor if your project involves multiple organizations not within the sponsor’s management chain. For efforts where the stakeholders are all in the sponsor’s chain of command, steering committee members should be at the next level of management below the sponsor.
The steering committee helps get the message out about the importance of the project to their counterparts in the stakeholder organizations. They help the sponsor telegraph the importance of the project. They also provide feedback to the sponsor – and you, the project manager – on how effectively your project is running from the stakeholder perspective. In short, they help you manage stakeholder expectations, which, for large projects, is extremely important.
The steering committee doesn’t make major decisions concerning the project – that’s the sponsor’s job. They do, however, advise the sponsor on major decisions. This gives stakeholders the opportunity to give input into important decisions affecting them through their steering committee representatives.
How do you gauge steering committee effectiveness? In my experience, the best gauge is when steering committee members feel that they’re being listened to and that they have a clear understanding of the project; the project plans, and they are aware of the major risks (and mitigation plans) and issues affecting the project.
Another gauge is the number of surprises that crop up. If you’re doing a good job of relating risks and issues to the steering committee, then they shouldn’t be surprised when your sponsor has to make a major decision – such as pushing-out a go live date by six months or adjusting project priorities.
If your steering committee is complaining about being caught by big changes made in the project, then you should really look at how well you are communicating risks, issues, and plans to the steering committee.
User Representation – The User Advisory Group
Now that we’ve taken care of the sponsors and stakeholder management with the steering committee, let’s turn our attention to the end users. These are the people that will have to live with the decisions made during the project.
End users can, ultimately, determine if your project is a glorious success or an unmitigated failure. You can deliver a new system having the slickest technology that’s the greatest thing since sliced bread, but people don’t have to use it. And if they don’t use it, then you’ve just wasted a lot of people’s time and a lot of money.
Years ago, an organization I worked for rolled out a new travel system. It was actually a nice system – well designed, easy to use, and it all ran in a web browser (the earlier system used client/server technology that was the “big thing” at the time before the web). The project did a smashing job delivering the system in a matter of months (it was an off the shelf system that required little coding to work) and rolling it out to the work force.
A month later, the organization went back to the old client server system. Fingers were pointed. A head or two rolled.
Could things have turned out differently? If the project had engaged their stakeholders in the beginning, perhaps they would have found a way to address the concerns of the supervisor responsible for approving travel and travel expenses. They weren’t involved in the project and when the system rolled out, they discovered that they would have to personally approve travel and expenses in the system (not surprisingly, as the regulation required).
The way travel approval worked was that most supervisors delegated approval responsibility to an administrative assistant, a role that did not have the authority for approvals in the new travel system. This forced the supervisors to do the approvals in the new system. They rebelled, and the system was quickly abandoned. If the project team had worked with the supervisors to begin with, perhaps a new approval process involving administrative assistants could have saved the system.
You don’t want to be that system – you want engaged stakeholders that can help you overcome hurdles like the one I described above. They can tell you were the problems are likely to come from using their perspective. That’s why you need a user advisory group to help you navigate potential pitfalls and help ensure success.
The user advisory group should have not more than nine well-respected intended end users of the system. If you can segment your end user population into groups, like the clerk’s and the public defender offices described in my example above, consider having a representative or two from each group. Also consider geographical representation, if it makes sense.
The important thing about picking user advisory group members is that they should be business experts first. Familiarity (or comfort) with using IT systems is good, but you really want people who are experts in the business. If you do some investigating of the stakeholder population, you’ll find out who these people are. They’ll stand out, as they are usually the “thought leaders” and readily recognized as experts by their contemporaries.
When you select the user advisory group members, make sure that you don’t end up with a group that never questions anything your team does. It’s always good to have at least one person challenging the status quo. After all, that’s what your project is doing, isn’t it? Of course, stakeholders can take things too far sometimes; so don’t hesitate to remove someone if they become so negative that they become a distraction and impede progress.
The user advisory group can be a big help with your project in these areas:
- Stakeholder communications – advisory group members can form an alternative, informal user communications network. Often, an informal network like this will have more credibility than your official communications channels.
- Managing stakeholder expectations – the give and take helps the stakeholders understand what the system will really deliver and what it won’t (or can’t). If user expectations are too high, then it could be tough to get the users to accept a perfectly good system. Too low, and they may ignore the new system altogether. Expectation management helps you find the “sweet spot” – and you can’t do that without knowing your customers.
- A source of subject matter expertise for defining requirements – since they know the job, they know the requirements. They can also help your team identify bottlenecks and efficiencies that will make them more productive. And more likely to use the system because they will have helped design it.
Special Activities – Work Groups
Sometimes there may be certain requirements that are beyond the capabilities or expertise of the User Advisory Group. Let’s say there is a need to define some technical requirements needing the skills of IT specialists working in the end user organization (as opposed to the organization “owning” the system).
Consider creating a workgroup staffed with the IT specialists needed. Just make sure that you clearly define what the Work Group will do and how long it will be in place. I suggest having the Work Group report to the Steering Committee rather than the User Advisory Group.
Also consider having at least one person acting as a liaison between the project or program (discussed in the next section) team and the Work Group if the findings or results affect the project or program.
Projects, Programs and Agile
I use the term “project” a lot in this article. One thing I don’t want you to go away with is the thought that I am suggesting that every project have its own stakeholder governance structure.
Instead, think in terms of programs, which is another, perhaps more effective way of organizing your projects. A program is a grouping of related projects, systems, and other activities. For example, a program may consist of:
- Two legacy systems
- A data warehouse and business intelligence tools used to operate on data captured and maintained in the legacy system
- A technology refresh project to replace one of the legacy systems
- User support and user training functions
Think of using one governance structure for the entire program. The same Steering Committee and User Advisory Group could apply to providing input to all of the activity bullets I listed above. The Sponsor would sponsor all of the projects assigned to the program. (For smaller, less impactful projects, the program manager may serve as the project sponsor.)
Where does Agile fit into the stakeholder governance approach I’ve described here?
It really should not make any difference. You should still organize your IT efforts into programs, and you should still actively manage your stakeholders to help with organizational change management issues.
The only real difference I see with Agile is that instead of having “classic, old school” projects to deliver new and refreshed technology, it’s delivered through Agile development.
Another “old school” concept is that of projects and operations and maintenance activities. In the “old” way of doing things, a project would beget a system and the system would be operated and maintained while it served the users. Along the way, a new project would launch to pump out a new version of the system containing bug fixes, new features, and adaptive changes.
Today, we have “DevOps”, which combines development and operations and maintenance. Instead of getting a new version of the system every six months (or maybe even longer!), the system receives updates much more often (say every month).
The key similarity between “old school” and DevOps is you still need to train and support the users, so that’s not going away. The big difference is that, if you have the budget, the Agile developers are constantly updating the system and it never ends. Presumably, any new technology refreshes would go out with the updates. Instead of having a situation where the users get “lurched” from the legacy system to the refresh, they are more gently transitioned from the old to the new.
One more thing – before you go down this road setting up a new governance structure and signing up a lot of stakeholder, check around and see if some form of governance doesn’t already exists. Perhaps there’s something in place that needs some adjustments.
In any case, setting up a governance structure is a great way for your customers to gain a sense of ownership of the system. They’re the ones who are going to use it to help them do their jobs in a better, and (hopefully) more enjoyable way. You want to them to “get their fingerprints all over it” and help you and your team be successful. Having stakeholders involved in governance is the best way for that to happen.