Decision Making, Politics, and Procurement
Updated: Nov 4
Author: Phil Clark, Founder of Embedded IT.
When I consider the complexity of some of the larger IT projects out there, it often makes me wonder how on earth they ever get anywhere. Due to the variables surrounding technical, operational and commercial requirements, it takes a solid structure and a lot of navigation to get to a position where all parties are in agreement, in terms of what needs doing. Furthermore, it is when the parties cannot agree that the risk and delay occurs. So, is there a good way to manage this aspect?
Technology, ways of working, cost, legals, etc., are all matters of fact. They are also often in the form of an inventory, a working process, or a contract. Political requirements, however, tend to build on the basis of opinion and personal agenda. This is clearly risky when complex organisations are involved, as competition and point scoring are usually part of the agenda. Additionally, in larger organisations where decisions are made based on an unstated personal agenda, this can be difficult to resolve and devastating to the project. Exposing and removing these agendas to support successful decision making is therefore critical to the success of a complex procurement project.
Singularity of ownership in this context is critical. If you need to move quickly, you need pre-agreed, clear demarcation for accountability. This ideally needs to be with a single person as opposed to a committee or a board. Identifying the key stakeholder or sponsor has got to be the first action of the project, as well as listing all of the decisions that are to be made, and identifying the ultimate decision maker for each. When more than one individuals input is required for a decision to be made, it should be the responsibility of the ultimate decision maker to consider other opinions or suggestions, but fundamentally the final decision is still theirs to make. Therefore, picking a strong individual as this decision maker is critical to the project’s success.
Typically, in large IT sourcing projects you have procurement and IT teams. Procurement teams are generally unfamiliar with the detailed technical requirements, and so rely on the technical and operational knowledge of the IT teams for the project to progress. Similarly, IT teams are generally unfamiliar with the requirements for commercial or legal aspects of the projects and rely on the procurement teams for such insight. This creates ownership problem number one – should the process be “owned” by procurement or IT? This is a complex question. Responsibility for compliance with governance falls to procurement, but the success of the service that is being sourced falls to IT. In my opinion, the success of the delivery out-weighs the compliance aspects of the project (within obvious reason), and therefore IT should be the ultimate decision maker.
IT sourcing is however more complex than that - especially in projects that transcend more than one layer of the technology stack. Outsourcing your Wide Area Network is relatively straightforward; you engage the Head of Connectivity/Telecoms/Network as a service owner, and such person then has ultimate ownership of the service. However, where you are outsourcing “all infrastructure” components, or moving to the cloud, this impacts multiple teams and therefore ownership is blurred.
This creates ownership problem number two – who is best placed to be accountable for this style of sourcing? Providing you are looking to secure a single supplier for all aspects of the service, the person with responsibility for the highest position on the stack (where LowàHigh runs WAN, Data Centre, Hardware, Middleware, Application, Business Process) should take responsibility for the decision. This is because their services are dependent on the downstream infrastructure components. Clearly, the CIO would be ultimately accountable in this style of organisational model, and should the project impact any staffing aspects, then a more senior sign-off may be required.
SaaS style services also drive a different dynamic. Fundamentally, the “shadow IT” phenomena of a business user procuring a service outside of the remit of IT makes for difficult management. Whereas, the Business Process Owner is the highest point of the stack, and these roles usually sit outside of the IT function.
The lack of understanding about the impacts of this product acquisition on the lower parts of the technology infrastructure makes things difficult. Making 10,000 users in a single office dependent on Salesforce CRM without considering internet bandwidth might be a mistake. In this situation, I see procurements role as brokering cross departmental discussion and approval. Although the ultimate decision should still rest with the Business Process Owner, inputs from IT and procurement should be actively sought and not overlooked.
Security and regulatory compliance is also a critical consideration. Clearly, in businesses where regulatory compliance is key, if a decision has the ability to compromise the security or compliance posture of a business, the power of veto for a decision is essential. In this regard, security or compliance teams hold a substantial amount of power. However, their influence and “acceptance conditions” should be considered from the outset, not as part of the final supplier selection. Providing all suppliers have met the acceptance conditions for a compliant transaction, their influence should be minimised. This removes the danger of an overzealous security manager’s opinion overruling the right decision for the broader company.
Clarity of roles generally needs careful focus. When people are acting as interim or babysitter managers for various functions, there must be an absolute guarantee for no conflict of interest. Fundamentally, in most complex IT procurement projects, there is a multi-year facet to a decision. Therefore, having a temp involved in a major decision making process is risky at best. Ownership of the decision should be with the person who truly holds responsibility for the decisions outcomes - without longevity in place, the accountability is diluted to a point of lack of long term interest.
All of the above points can be swept into a single “align your objectives” broad statement. If the IT and procurement teams are consistently focussed on what good looks like, and there is mutual agreement on the objective, then conflict is minimised.
This is one of the biggest lessons I’ve learnt since moving into complex IT and procurement projects. If there is no common goal, you are left vulnerable at every stage of the process. Combining this with personal agendas or opinions makes for a turbulent and uncomfortable process - one that is likely to fail. On the contrary, if all participants are aware that the end goal involves 5 or 6 high level principles which are at the centre of every decision, the chances of success will be maximised.
Both IT and agile sourcing processes are only able to succeed if the political will to succeed exists. Effective political alignment can add substantial value to an IT project. However, unproductive political alignment could be the end of your project plan. While commercial, operational and technical aspects of a project are easily understood, the political aspects are more complex, and therefore come with elevated risk. Leveraging external consultants in this regard can add significant value. As a genuine independent with no vested interest, we can genuinely guide the project towards the common goal without being swayed by any hidden agenda.
Get in Touch
Would you like to discuss your IT requirements with an expert? Don't hesitate to reach out today, and we'd be delighted to help.