Digital transformation stuggles

“Any advice on how to bridge [the IT/Business] gap? Are there any rules/guidance on how a technology dept should be defining/presenting products to business functions in this context? Also, guidance on the relationship between projects/products in this context?”

I’ve received these questions from a reader who finds themselves inside a company undergoing a digital transformation. Actually, they describe the situation in more detail and there are questions about the differences between products and projects, the role of BAs and how to organise the whole place.

Let’s start with Projects v. Product

Projects have end dates – or, at least, are expected to end. Projects are usually a batch of defined work which is expected to bring about a defined outcome. Projects may run past their expected ends, may expand in scope and may fail to deliver the intended benefit but while managed as a “thing that will end” they remain a project.

Products are ongoing, in a commercial environment products continue to deliver revenue and continue to require work.

In the pre-digital age a project might developer a new product, the project ends and the thing is passed to manufacturing, or service agents, for delivery. In the digital world this doesn’t happen. Products require continued attention. This may be to keep them competitive – add capabilities competitors have; or to keep them operational, e.g. update libraries which have security flaws.

With digital products it is hard to define when new development gives way to “manufacturing”. Techniques like Lean Start-up, Minimally Viable Product and Product Discovery exploit this ambiguity to leverage learning and in-market learning. Before digital this “expeditionary marketing” technique was expensive.

There is a difference in funding too. Projects are typically funded in their own right (how much work is involved? what will that cost?). Conversely the teams which support product teams should be funded in their own right and trusted to do what delivers benefits. Product teams should be able to demonstrate at the end of the funding period that they have delivered more benefit than they cost.

Inside corporations IT Departments used to delivery projects which aimed to improve business effectiveness or support a non-digital product. In the digital corporation the business is the technology and the technology is the business, it no longer makes sense to separate technology departments from the business. The need for rapid feedback loops between “the business” and “the technologists” means that they are one team. Anything that gets in-between slows down the processes and hinders communication, and thereby damages competitiveness.

This means that digital product teams are responsible for sourcing and deciding their own work. Whereas before the business would decided it wanted to do an IT project and the IT department would be expected to deliver it now, the digital product team would spot the need or opportunity to change the product and decide to take action. They reason what using their resources to enhance the product will deliver more benefit than it costs.

The digital product teams will contain both the “supply” skills to do the digital work (e.g. programmers, testers, UXDs, etc.) and the “demand” skills to understand customers, monitor market changes and determine responses (e.g. product management and business analysis). The exact mix of inward facing BA skills and outward facing product management skills will vary depending on the product and market. Deciding what to do is product ownership, and the person task with making the “what shall we do next” decision is a “ProductOwner”. They may be supported in that role by additional BAs and/or Product Managers.

But all this doesn’t mean that projects cease to exist. Not everything is a digital product – the company may want to move offices and the move itself could be a project.

There may even be projects which impact digital products. For example, the company the new office needs a new phone system and decides to avoid the cost of laying cable by using a virtual VOIP system. This requires software on desktops plus audio equipment. It may also mean the products running on those desktops need to be interfaced to the new telephone system and the interfaces to the old PABX retired.

A office move project like the may well use Business Analysts to investigate what is needed to make the move and resulting changes. Meanwhile, the digital product teams, who may not even know an office move is planned, are unlikely to see the telephony changes early. So at some point the office move BA will need to work with, and inject work into, the product teams.

Because projects come and go, it may be that some BAs rotate between projects while other BAs are embedded in product teams. However, because digital companies will have more products and fewer projects it is likely fewer floating BAs will be needed while more remain with their teams. And because products have an outward facing, customer, dimension, many of those BAs will want to acquire some product management skills.

The product teams will probably have a stream of product development work they want to pursue to make their product even better. They will also have “business as usual” work to keep the product operational. Add to that the work arising from the projects that demand attention and you have a lot of work to do. Rather than privilege any one stream of work its it better to think of it all as “work to do”, work may come from different sources but it all gets done by the same team.

Where one team has to support multiple products things get more complicated. One product owner might be able to cope with them all it also means there might be several each with a different product focus. In these cases they either need to agree between themselves how capacity is allocated or, more likely, someone needs the authority to make those calls.

Ultimately the “IT department” and floating BAs may well go away because there are business lines, which are digital and are serviced by business focused teams containing all the necessary skills.

It doesn’t make sense for digital products to be run out of the IT department because digital products are more than just information technology, they are the business. You could say that the whole business needs to move into the IT department but really we want the IT department dissolved. Rather than structure a company as manufacturing, IT department, a marketing department, services etc. what we want to see is “Amoeba” teams which contain enough technical skills, enough marketing skills, enough delivery skills and so on.

That change isn’t going to happen overnight so while we are waiting to dissolve those different functional units companies can establish product teams where people from different functions work together. The programmers might still report to “IT” and the marketeers report to Marketing but success is judged at a team and product level.

In many ways what I’ve written here is a summary of the model I put forward in Continuous Digital: in a digital world the work is continuous, the product is the technology and companies need to restructure themselves accordingly.

Verified by MonsterInsights