Before the cloud, IT projects had a definitive start and end. Choosing the right leadership team to keep all players on task was paramount to success. In the cloud era, instead of distinct start and end points, IT leads continual cycles of change and improvement. In a way, this means that projects are never done. As well, projects are continually evolving.

Project leaders must sometimes make decisions on the fly about platforms and technologies, to minimise redundancy and sprawl or in response to an urgent business need. Architectural design depends upon understanding the vast array of new technology choices. Security and performance monitoring are a daily challenge, as is managing shadow IT. With cloud computing, many IT departments are leveraging new DevOps processes and tools to simplify and improve workflow and decision-making. Yet organisations still need project stakeholders to maintain equilibrium.

IT project stakeholders play a pivotal role in keeping everyone on the same page. They assure alignment with the organisation’s priorities and business requirements and facilitate decisions when there are competing objectives.

Additionally, as organisations begin to incorporate new public cloud IaaS and PaaS, AI and container technologies, project stakeholders can mitigate the risk of analysis paralysis, which delays decisions and creates infighting and waste. Their ability to define what is “good enough for this iteration” keeps the wheels moving and minimises confrontation between team members.

Selecting with simplicity in mind

When it comes to choosing stakeholders, more is less. I’ve been part of engagements where there were more than 10 stakeholders. When it came time to make decisions, everyone looked around the room for someone to take a stand. Once someone did, it was nearly impossible to reach consensus. From experience, I’d say it’s best to aim for a small group of stakeholders with clearly-defined roles.

IT project stakeholders should typically encompass three key roles:

• Business owner: This person is often the owner of the application being developed or migrated. They must effectively represent and communicate the requirements of the project’s end users. Their workload is the heaviest at the beginning of a project
• Organisational leader: Often the IT executive who serves as the project sponsor, this person’s approval is required on the proposed solution for the project to proceed. This person should be actively engaged throughout the project
• Functional influencer: Not always holding a big title or budget, this individual is someone whom the team looks to for guidance and whom can garner the support and buy-in for the chosen direction

Typically, the organisational leader works with the project lead to select the business owner and the functional influencer. Other project VIPs might contribute to these decisions as well. Don’t rush the process. If you choose the wrong business owner, the finished project won’t meet business objectives. If the organisational leader is unable to remove barriers and make informed decisions quickly, a project will go off the rails and experience significant delays. An ineffective functional influencer can’t build the trust necessary to convince their peers of the chosen direction, resulting in productivity and morale issues.

When winnowing down the list of stakeholders, only consider individuals who can have influence throughout the entire life cycle of the project, versus someone with a specific area of expertise and authority such as security. If there’s disagreement when selecting the best stakeholders, the project lead should have the final say.

Resolving conflict

Invariably, project stakeholders will have moments of disagreement with each other and with other project influencers. That’s normal, until it’s not. Things seem to be going wonderfully well and then suddenly, in the middle of a major milestone, a stakeholder goes rogue. He decides that the current direction is not working and begins to needlessly disrupt progress. It’s okay to revisit strategy during between milestones, but somebody who repeatedly raises flags without suitable cause is dangerous.

The classic adage of “an ounce of prevention is worth a pound of cure” directly applies here. The best way to prevent this from happening is to engage all stakeholders at the onset and throughout the project lifecycle. An engaged stakeholder is much less likely to go rogue, since they were directly involved with the decision making at every step. This won’t dismay all rogue actors, however. There may be political reasons behind the derailing efforts. At this point, the project lead may need to step in to mitigate the concerns and/or bring in higher ups, such as the CIO or CTO, to resolve the conflict.

In some cases, others will push to expand your stakeholder group. For instance, many teams have multiple functional influencers or organisational politics deem it necessary to include a certain individual. Resist the temptation to add more stakeholders, unless exclusion of an individual could backfire by splintering support into opposing factions.

IT organisations are much flatter than they used to be and while that’s great for fast-paced collaboration and innovation, it’s not helpful when roadblocks arise. Choosing a small team of effective and well-respected stakeholders who can lead the troops through minefields is the insurance that every project needs, big or small.

Interested in hearing industry leaders discuss subjects like this and sharing their experiences and use-cases? Attend the Cyber Security & Cloud Expo World Series with upcoming events in Silicon Valley, London and Amsterdam to learn more.