Cameri

If you ask ChatGPT what a project model is; it would tell you that it refers to a framework or a structured approach used to plan, execute, monitor, and control projects. It encompasses various methodologies, techniques, and processes that guide the phases of a project from initiation to completion.

So much from ChatGPT today…

In my experience, a choice of the appropriate project model is often reduced to a binary discussion between waterfall and agile methodologies. This is an important discussion (some authorities might even think it is the only important consideration to make), which could be a subject for another Point of View from me later. But there is a risk is that the focus on agile/waterfall discussion might distract decision-makers from an equally important topic: when an organization (a Client) is planning a change project, how to ensure that she/he is set up for success from a structural and organizational perspective. Ie.: What capabilities are required to deliver the change; does the client have access to these capabilities internally, or does the client need to acquire external expertise and/or capacity? And if the client chooses to engage with an external supplier, what delivery and commercial construct should then be chosen?

Here is my bottom-line message, which will be described in more detail below:

1. The client needs to be aware (and plan for) all elements of a change project. This is most challenging when the client is facing a large and complex project and the client lacks experience from similar work.
2. The client needs to decide what elements of the change it can do itself, versus what needs to be supported by external suppliers. This might also be a challenge, as it will depend on the client’s strategy, capacity, risk appetite, prior experience, etc.
3. The client and the supplier need to have a shared and symmetrical view of each other’s roles. The parties may have a shared interest of “kicking the can down the road” on this topic, and it does not hit the agenda until there are real delivery issues.
4. The contract needs to reflect point 2 and 3.
5. Hence – the relevant project model should be chosen after careful consideration of the elements mentioned above.

The partner model could apply when the client does not have sufficient experience to do the project strategy and design upfront, so the client will need to work with an external organization to design the overall change. If the client lacks sufficient capacity/capability to deliver the overall integration, and/or components of change, the client may choose to include (parts of) this scope in the partnership agreement. The client would then see the partner as a safe pair of hands to make sure delivery is successful. It could also be that the Client see that the business criticality of a transformation is too high, so they want to find a partner to share the risk and to increase the probability of a successful outcome.  

Often the contractual construct would be tied to business outcomes. The client should expect the partner to have skin in the game, so a balanced risk sharing (bonus/malus) model relative to business outcomes should be considered, ie value based, target pricing, shared upside/downside etc. Such model will set the expectation of mutual accountability to deliver the expected business outcomes.

 Hence - a partner model is one where the objectives of the client and the partner are shared. Meaning that the partner in all situations would be incentivised to deliver on the client’s needs, always to deliver on the client’s best interests. This will not happen by accident – it does require trust-based collaboration and both parties need to be incentivized commercially to behave accordingly.

 What clients could be best served with this model? A typical client would lack in-house experience of planning and leading major transformations, and would look for a partner that brings methodology, experience, and credentials. Typically, the partner will keep a strong hand on the steering wheel when the client has set the compass course, and the client would be willing to let them do so. This is a model where the partner is committed to outcomes rather than output, so the scope would also then typically be covering most aspects of the change, ie extends into broader business realms than IT. The model would also be applicable when the client is yet to understand and describe the scope of the transformation. They would need external help to describe the blueprint and prefer the same party to do the project implementation.

A risk with this model is related to vendor lock-in. Although this can be mitigated, the barriers of breaking out can be high. Also, to be noted, there is a risk that the client would avoid taking sufficient ownership and accountability to the transformation. It is necessary to mitigate this risk by explicit contract clauses on knowledge transfer. A clear success factor will be active client participation and involvement, including a defined exit strategy. The client must also be aware that the partner can be accused of sitting on both sides of the table, which is particularly important to mitigate in the Public Sector.

The upside of this model is that the client will have “one throat to choke”. The partner cannot hide behind the mistakes of others and cannot make excuses. This should be incentivised further by a balanced bonus/malus scheme that keep both parties disciplined as things get difficult. The governance structure is straightforward, as there are usually only two parties involved, and it is easier to build a common project culture. But most importantly, this model, when successful, will be very efficient in terms of business agility and simplification of change order processes. When new demands or risk occur, business trends are shifting, affordability changes, etc; the project plans can be amended accordingly with limited contractual impact and delays.

It seems to me that this was a preferred model a few years back, but with the shift towards agile methodology and strengthened in-house capabilities, this model might have lost momentum in the market. Consequently, the vendor landscape has also changed, to reflect that there is an increase of small and medium sized projects, with lower barriers to entry, and lower financial exposure.

An integrator model could be applicable where the client does not have sufficient capacity/capability to deliver some/all of the components, nor deliver the overall integration (business and/or IT). The client will typically retain some management/oversight for integration and delivery. The design of the overall change is still owned and executed by the client, with or without help from external consultants on the “client side”.  

Often the contractual construct would be either T&M or fixed price (output) based. In some cases, even risk sharing, target pricing, bonus/malus models can be considered.

The integrator model would often exist in a multi-vendor environment, where the client would lean on the integrator to align plans, to help manage and control the delivery of the project. Compared with the partner model, the integrator model has some of the same benefits, but governance is slightly more complex.

What clients would be best served with this model? A typical client would already have a separate contract with a SW provider (for instance an ERP solution) and is looking to the system integrator market to get help for a safe implementation, maybe also multiple suppliers that has contracts for different components of the solution. Typically, the integrator would support in PMO, architecture and technical integration, and sometimes also configuration and customized changes. The integrator would typically work alongside with key client personnel on these tasks. This model would also require some degree of a scope delineation.

The risk of this model is primarily related to governance. The client will not have “one throat to choke” and needs to use the different contracts to mitigate and manage this risk. Contracts need to reflect adequate incentives and responsibilities to create a project culture of collaboration and high performance. The contracts also need to be clear on methodology, as misalignment between the different vendors would lead to high risk of failure. For example: one vendor on fixed price (cost focus), one vendor on T&M (quality focus) and one vendor with bonus on timely delivery (time focus) would indicate risk of project failure. You could view this example as exaggerated, but the lack of ability to prioritize between cost, quality and time is more common than you might think.

The upside of this model is that the client optimizes the market and buys the best products and services available. The client can use the best service integrator, the best ERP provider, the best subject matter experts. By this, the client will also avoid vendor lock-in. Obviously, the client will be more accountable for project success than in the transformation model, but with the benefit that the client will build structural skills and capabilities during the project.

The success of the integrator model hinges on the ability to collaborate effectively across the different parties. This requires contracts to incentivise collaboration, and that governance structures and leadership behaviours stimulate win-win-win situations. Particularly would the client and the integrator need to be fully aligned.

A client/vendor model would be applicable if the client does not have sufficient capacity and/or capability to deliver some/all of the components of change and will engage with vendors to deliver specific components or services. The integration effort and the design of the overall change is owned and executed by the client, with or without help from external consultants. 

Often the contractual construct would be either T&M or fixed price (output) based. As for all models, this construct can be applied on both agile and waterfall development/methodologies. 

A client/vendor model is one where the client has the required experience in designing and leading a transformation but want to buy best of breed SW and/or implementation support from the market. A typical usecase is that the client has strong IT capabilities and will buy the capacity required from the market – either to cover line operations to free up own staff to do the project work, or to buy for instance scrum teams from the market. This model also covers resource augmentation or “body-shopping”. In this model, it is possible to have framework contracts for multiple vendors for the same type of service, to ensure access to the needed capacity when the flexibility to scale quickly is needed.

What clients would be best served by this model? In this model, the projects are client led, so this requires the client to be fully accountable for the success or failure of the project. Therefore, the client needs to have experience, skills, and capabilities in-house. And would use the market to cover the gaps, capacity- or capability wise. This is typically a mature client, able to understand and mitigate the risks embedded in this model, and to extract the value from successful delivery.

The risk of this model is that there is little protection available if things go wrong. It hinges on the ability of the client to make the right choices to mitigate occurring risks. But it could also be organizational barriers, like limitations to how many people the client can throw at a problem. And in a tight market, it is not given that the vendors can come to rescue. If the client chooses to mitigate the risk of access to internal people by hiring consultants to do client roles; my strong advice is to make sure that the incentives are aligned with those parties doing delivery. Misaligned incentives are a red flag.

Another risk is related to scope management. When the client is accountable him-/herself, particularly in the agile world, it might be tempting to defer parts of scope to keep cost and performance indicators green. The project organization might declare success, whilst the underlying reality could be that only parts of the original scope is delivered. This issue might easier be addressed in one of the above-mentioned models.

A clear upside of this model is that the client can incrementally builds in-house capabilities, and the client gets less dependent on external support, hence the potential to do more within the same budget. With these in-house capabilities, the client would also typically keep their IT portfolio more up to date, and be less exposed to massive, high risk transformation projects. However, this requires that the client has a realistic and honest view on their ability to free up their own people. Many times, the clients fail to deliver upon their ambition, as it is hard to free up key resources from operational everyday work.

I have the impression that the client/vendor model has become more frequently used lately, and that clients take on more accountability for incremental as well as transformational projects. In my mind, the jury is still out when it comes to decide whether this is a durable and sustainable trend, or if a course correction is needed. If a course correction is needed, my anticipation is that this will be related to the aggregation of technical debt, and/or clients losing out in the war for talent.

A client that needs to go get external support in planning and delivering a change project can choose between the 3 models above. It is important to note that there is no “one size fits all”. All 3 models have worked, and all 3 models have failed. It comes down to what experience and capabilities does the client have, what type of benefits would the client be looking for, and what risk profile does the client prefer.

A mature client with strong in-house capabilities can benefit from the client/vendor model. A client with less experience facing a major challenge, would benefit from the partnership model. And a client that have some experience (and wants to build more), and would want to avoid vendor lock-in, could benefit from an integrator model.

Regardless of model; there need to be an alignment between the client’s business- and IT strategy. Particularly when it comes to decisions around what is core business functions, and what can be outsourced indefinitely. This will avoid the risk of massive pendulum swings.

And no matter what project model the client chooses, make sure to avoid misaligned incentives and contracts. The commercial structures must be aligned with the delivery model and the price model (for instance; a fixed price demand a fixed scope, etc). An important success factor is that client and the partner/integrator/vendor have a shared and symmetrical view on the role of each other. If there is a mismatch, failure is likely.

An effective public service offers safety, security and wellbeing for their citizens, and conditions for success for businesses and NGOs. Quite simple in theory, but hard in practice.

It is a paradox that a government knowing they have the ability to do more with less, and still chose not to. But we should bear in mind that there are many legitimate reasons for change resistance in public service. And…we should also challenge why many governments don’t do more.

Let me first describe the barriers for transformation in public service. Let us structure these in 3 different categories: Political-, administrative and psychological barriers.

Political barriers are in many ways a democratic imperative. If we for instance vote for a government that is against privatization of the public education or health system, the government is simply acting on the mandate given by the people. Even if there would be productivity gains to privatize, the political intent is to keep these services public regardless. That is legitimate and an expression of our democracy. And if a government is seen to waste taxpayer’s money, the people can change their government in the next general election. This is obvious, but still a reminder of why public service is denied the opportunity to solely look at the best financial option.

Administrative barriers are sometimes legitimate, but also frequently used as an excuse not to take difficult decisions. Risk management is important in all change. In private sector; money, jobs and brand reputation is at stake. But in public service, the risk management needs to be much wider, as the consequences of occurring risk might be tremendous. If the government don’t manage risk well, lives can be lost, our climate destroyed, businesses and industries erased, there could be structural unemployment and social unrest. Even war. And less dramatic, but often front and centre for public servants: the minister might be forced to resign.

So it is easy to understand that public service and public servants put emphasis on avoiding risk. And the easy way, is to do nothing. Which in many ways is a misconduct of service and a breach of the trust of the people they serve.

But let’s get real: what incentives are there to take risk in public service? Particularly by doing new things – things public servants have never tried and never done. As already mentioned, consequences of failure might be enormous. But at a micro level, for the individual that wants to improve quality of public service, or save taxpayer’s money: what’s in it for her/him? The budgetary benefit might appear at another agency/minister’s area of responsibility, while the risk and the investment fall on her/him. This is how the sectorial system works (however, sometimes mitigated by a strong Ministry of Finance). And running over time or cost, will certainly attract the attention from State Audit Agencies and media, leading to parliamentary hearings and even more publicity for the executive in charge. In theory, bonus/malus should be balanced. But in public service, this is not the case. The malus is very tangible and painful, while there is little upside and certainly very little bonus.

Lack of incentives are an important barrier. So is lack of experience. Most ministries and agencies have very limited – if any – experience with change management and delivery of large-scale transformation. For different reasons, the tolerance of partnership with service integrators or management consultancies are low. When a big program is planned, strategies developed and program executed, many of the leaders find themselves in uncharted territories. They are simply doing something very difficult for the first time and often have no one to ask for help or guidance. No wonder they try to avoid even getting started.

Some governments try to pay its way out of the complexity by adding risk contingencies at an unprecedented level. This risk contingency will represent a buffer that protects the responsible leaders and ministers. If the program overrun, the responsible parties could always trigger the contingency and still deliver on “the budget”. The problem by this approach is two-folded. First, the budgets of these mega projects are much higher than they could have been with a better project model and more reasonable risk contingencies. And since the budget is consumed for the original scope/purpose or something related, the taxpayers don’t get value for their money. Second concern is that since the contingencies are so high, there is less budget available to do the reforms needed. What if we could have repurposed the contingencies to cover a centrally managed industry standard buffer, and used the surplus to do more modernization?

Psychological barriers do also exist. Public servants are paid less than their peers in private sector. Yes, public servants do important jobs, but would they feel encouraged or discouraged to embark on a change journey? I don’t have any data to support this, but my impression is that more public sector leaders are keeping their head low, relative to 10 years ago. They would typically choose incremental over transformational; they would rather be safe than sorry.

Are they to blame? I think not. Media have become ruthless with the focus on individuals rather than addressing the structural issues. Political opposition have become populistic in their response to any execution challenges, rather than asking if these agencies and leaders are operating in a sound environment and given the support they need. State Auditors have the luxury of hindsight, which again media and opposition grab with open arms.

Our PoV:

We need to respect the legitimate barriers for transformational change in public sector. They are there for the greater good. But: we should forcefully challenge the structural issues that prevents public sector leaders from doing a good job. Let’s stop blame the individuals and repair the things that are broken. Create incentives, give the leaders a fair chance to succeed, acknowledge that many innovations will fail before it succeeds. Tolerance for failures is not the same as acceptance for negligence. And try to be pragmatic about what government is good at, and what private sector can do better.

If public service can create a culture for change, there will be an opportunity for doing continuous improvements. And then, the agencies will be learning, developing and rewarding organizations. Attracting even better talent, retaining the best leaders.

The people will appreciate such behaviours, feeling safe, secure and well. The businesses will see that the government is delivering the optimal conditions for success. A productive and effective public sector will then deliver on its purpose.

Transformation is a fundamental change in business models, structures and/or organization. You are one thing today, and something different tomorrow. In private sector, this happens all the time. New business models, new technology and many other disruptors allow for some businesses to win and scale, and others to cease to exist. The examples are countless; Kodak, Nokia, Tesla, Netflix, Klarna etc.

Turning to Public Service, the use-cases are usually less transformative. Not necessarily less impressive, just less transformative. But there are some good examples out there, programs that have been truly transformational, creating value for citizens, businesses and society. Tax agencies in many countries have been among the frontrunners. So has Social Security agencies and Customs.

What do these frontrunners have in common? Huge volumes of transactions, ie tax returns, pension payments, customs declarations etc. These volumes are for many years already moved to electronic transactions, highly automated, which has allowed the civil servants to be focused on more value-oriented tasks (or made redundant). As technology has evolved, these same agencies have included their clients (users, citizens) into the processing by offering advanced self-service solutions. This has been made possible through good technology backbone and safe interaction on sensitive matters.

Other public services are globally less advanced and mature. The Police services (and even the entire Justice system), the Health service, the Education system and partly also Defence are in general behind the curve. Possibly because 1 Euro investment into process improvements and IT is often 1 Euro less to visible police, to doctors and nurses and to troops. Less police officers, less nurses and teachers are a hard sell politically and in society overall. The consequence seems then to be to kick the can down the road, widening the gap between the high and poor performers.  

I would argue that the level of sophistication is in general higher in central government than in local and regional government. Some regional and local governments are mature and expansive, but I this is the exception of the rule. As many local governments are inefficient and have poor citizen service, the value people get from taxpayer’s money is even less.

Our PoV:

In most countries, you would find some rather advanced and effective Public services, with highly automated processing and offering relatively high service levels. In many ways, these agencies can stand a comparison with many transformations in the private sector.

Estonia is frequently mentioned as a country that has successfully transformed its public services into an effective and citizen friendly organization. This was allowed by leapfrogging technology post the fall of the iron wall, helped by EU funds and a progressive government. Singapore Government is also known as a high performing government, setting the bar for public service no lower than private sector. The way Singapore recruits and retain top talent is for example quite unique and not very different from the corporate world in many ways.

And you would have some countries; agencies and services that don’t even have the fundamentals in place. So, the answer to the headline question is yes. Public Service have the ability to transform. But chose to do it rather inconsistently, and parliaments, citizens, businesses and media seem to accept this mediocre approach.