In a digital enterprise, the business is IT and IT is part of the business. The question whether a separate IT department is still required is a good one. But let’s leave that one aside for the moment and look at how we can get business and IT fully aligned in delivering the functionality required to deliver the services required.

Many business people keep complaining about the slow response from their IT counterparts while IT highlights the multitude of demands from the business to explain delays, changes in priorities and inability to deliver demanded functionality in time.

The use of agile development methodologies have involved the business in the development process, ensuring IT deliverables truly address the needs of the business. That’s a first step. The development of small blocks of functionality through a sprint based approach, the implementation of DevOps techniques have all contributed to getting functionality out in production faster. But isn’t there something else?

Is IT responding first to the most important requests? Are business and IT thinking about the return of the functionality required? This is where portfolio management comes in. Can we prioritize the needs of the business and have them delivered in time and in budget?

To do that, there are a couple elements that need to be put in place. Let’s describe them:

Develop an Enterprise Architecture Framework

Companies have their own ways of working. They execute a series of intertwined business processes allowing them to run their business. These processes are supported by a series of information items that are critical for the enterprise operations. Clearly documenting these processes and information items facilitates the discussion with the IT teams by clearly depicting what is changing and which functionality is required.

But most companies do not have such framework documented. That makes it more complex to clearly state requirements. Building such framework seems a daunting task. The good news is that in most cases you do not have to start from scratch. Several industry segments have standard industry process models that can be used as a starting point. The Communication and Media Industry has eTOM. In the Manufacturing Industry, the Supply Chain Operational Reference model (SCOR) is widely used, while BIAN (The Banking Industry Architecture Network) addresses the financial services industry.

These models typically address the first three process levels in their design. The reason is that those are mostly common between enterprises allowing them to be “generic” and enabling companies to benchmark their operations. The BPMInstitute describes the levels in a blog post titled “When you say ‘Process’, what do you mean…?”. You will have to develop level 4 and potentially level 5 and 6 (where it makes sense). That is where you will describe your specific implementation and where your framework will differ from that of your competitor.

Grouping the process steps together will allow you to highlight the organizational boundaries and clarify the responsibilities.

Establish your IT functional architecture

Once you have your Enterprise Architecture Framework, you can now develop your IT functional architecture. It will describe how the functionality is implemented in the IT systems, where each function is run and how the functions are integrated. It should be complemented by a technology architecture describing which technologies are used to link functions together, to shield others, to ensure system responsiveness, high availability and all other aspects that IT has to handle.

Let’s now take a look at requests coming in from the business.

Manage your portfolio from a business perspective

The IT departments works of budgets and has a certain capacity. The business has a set of requirements that evolve in function of the strategies and tactics. So, how can we manage supply and demand? This is where portfolio management comes in.

Let’s think about a request for the development of a new piece of functionality associated with one of the existing applications. How would such process work?

1. The business owner describes the additional functionality required by referring to the enterprise architecture framework and highlight what should change from a business process perspective

2. He/she then highlights the business benefits expected from this change or new feature

3. The request is added to the list and submitted to the business & IT governance board

4. The board reviews the requests, starting with the one providing the biggest business benefits and assigns a solution architect to the one(s) it believes can be delivered shortly.

5. The solution architect analyses the requirements, and using the functional architecture, highlights what has to be done to deliver the appropriate functionality.

6. He/she then identifies if assets exist that could be re-used to limit the amount of additional developments required, and estimates the effort required.

7. During the next meeting, the governance board assesses whether appropriate resources are available to perform these developments, or whether, within the IT budget, resources can be sourced externally or the project can be delivered by a third party.

8. If approved by the governance board, the developments are initiated and the project is delivered.

Obviously, throughout the life of the project, achievements will have to be monitored and delays or financial overruns highlighted and acted upon.

portfolioThe queue of requests constantly evolves in light not only of the business demand but also of the business cases of each request. If the projects use agile development methodologies, the governance board has the opportunity to stop a project at the end of a sprint, take the available functionality in production, if that makes sense, and divert the resources to a high priority request. That gives the organization the flexibility to provide the flexibility required to address the needs of the business.

By involving the business in all steps of the decision process visibility is not only created, but now the business is an integral part in the decision process. Blaming IT is no longer on the table. Sure there will be discussions on why it takes so long to deliver a given functionality, but this is an opportunity for IT to highlight all the aspects needing to be addressed.