Part 3: Why the stakeholders should not run their digital projects

This is the third post in my series about Agility for traditional companies. In the other two we discussed a) what waterfall projects often fail to deliver, and b) a mind-frame for how to think when implementing software.

In this post we will discuss why the structure of working of traditional companies often gives poor results in digitalization projects. Hence this post is also about “setting the scene” for future posts that will give more tangible advice regarding how to start an agile transformation.

It is not uncommon for traditional companies to run digital projects within the operational department with the biggest need for a better technology. Hence a project aimed at improving documentation and traceability of products is run by the Quality Department, a project with a purpose to improve fulfillment processes is run by the fulfillment team, etc.

This may sound logical and right, but is in fact a common mistake. There are many reasons why this is the wrong approach, and here are a few:

1. Very few processes stays within one single team or department. Usually more stakeholders need to be involved from other teams. A project conducted by one of the sister teams will get prioritization and bias problems.
2. People who are experts in fulfillment (or any other function) are not experts in designing software or even to give the fulls scope of requirements for such a project. They often end up in the WHAT discussion and forget about the HOW.
3. Project run in parallel silos will inevitably get problems with alignment, and who is the final decision maker?
4. Due to lack of competence in the digital space, the projects tend to be run by external consultants and thereby the company is no longer in control of the projects and the outcome.
5. While an improvement project is being done, the day to day work also needs to be conducted. This means a slower development and thereby more time  will pass before the department/team can benefit from the development.

It is important to remember that software initiatives, and the projects to carry them out, need professionals. Just as you need professionals in Accounting or for HR personnel. 

For companies that want to gain speed and improve the outcome of their digitalization projects it is therefore crucial to set up an organization that can handle this in a professional way, from a holistic standpoint and without bias to one or the other department. 

Please note that we are not talking about old school IT departments here, but a function where the various processes has a digital Product Owner. I sometimes call this “Digital Operations” to show the importance it carries for operational improvements within a company.

This organization needs to sit as a hub between the other various departments, and it needs to be freestanding from them. Each one of the other departments/teams are stakeholders to this organization:

What differs Digital Operations from a classic IT organization is the cross-functional way it operates, and thereby the competences needed. Another way it differs is that its Product Owners are usually not System Owners, but owners of a process (more about this in Part 4).

The classical IT organization, becomes a part of the Digital Operations, and can in some ways be regarded as our DevOps organization.

The below is an example of a Digital Operations organization can be set up, and if one or more of the functions are deemed unnecessary, you can freely remove them. It is also possible to combine two functions/roles into one, of course.

Also, depending on the size of your operations you need to have more or less people reporting to the lead functions illustrated below.

Let me explain some of the roles above and why they have been placed in the Digital Operations department in this case:

Digital product Owners: are the ones that are responsible for a function or process within the company. They do normally not need to be very technical but should basically be business analysts with a tech flavour to be able to work with stakeholders and plan and design the functionality needed. These are the ones who take over the responsibility for building or setting up systems from the day-to-day business.

DevOps: This is what most traditional companies think of as the “IT Department”. Here is where we find the system owners and the engineers. They have the responsibility for keeping the systems running and for making improvements, changes and new development.

IT Security: IT Security is vital for any company and since each application built needs to be secure they need to sit closely to the development. This team can also be responsible for legal aspects such as GDPR.

Infrastructure: Each company needs to have hardware, conference solutions etc. Therefore we need a dedicated owner of these more “hard core” aspects.

Digital Procurement & Controlling: As mentioned a lot of companies let each team/department run their own projects. this usually results in a lot of solutions that are similar, overlapping or totally redundant. It is necessary for a company to centralize this in order to become efficient and save money.

Agile Lead: This is a function that, in theory, could be placed somewhere else in the company organization. However, since we are here talking about traditional companies, not used to work in an agile way, the competence about Agile will mainly be concentrated in the Digital Operations department. Therefore this is where they will easiest find a home. When a new project is to start they are thereby readily at hand to coach and teach both stakeholders and people in the Digital Operations so that the agile principles are followed and developed.

Operational Excellence: This is another function that could be placed elsewhere, and sometimes we find this function in finance. However, since we are shifting focus from “systems” to processes, and very few processes stays within one department, and their role is to help the Product Owners to create the most efficient roadmaps for operational (and other improvements), I find it very useful to place them in Digital Operations. 

Support: This function is to be seen as the support team., hence both supporting Suppliers, Customers and internal users with technical problems and user support. It is true that it is very common to place this team as its own team or connected to other departments. However, proximity to the Product Owners and Engineers gives big benefits when it comes to decide what needs to be modified and/or improved. In effect they become the voice of the users after roll-out of a new function or system.

In part 4 we will discuss why system based development is less efficient than process based development.