The great divide

The great divide. I continue to be amazed that with so much focus on agile and lean methodologies that on IT projects there is still an artificially created divide between employees working in the IT department and those working in the rest of the business. Teams are formed and lip service given to setting up cross functional representation with IT members and "business" members. Very quickly these teams break down into their IT components and the rest. Either it becomes an "IT project" and the IT team takes over and the rest of the team drops to the periphery and waits for a solution to be delivered. Or, perhaps worse,  the IT team walks always and leaves the rest of the team to come up with a solution outside of IT. Depending on where you sit it becomes very easy to point fingers at the "other" side and blame them for not coming to the table.

The important thing to remember is that IT is a service to the rest of the business. It rarely produces a revenue stream but is there to enable the business to utilize its information assets to the highest level. However, it is also clear that Information assets are often under valued and not fully utilized by the business as a key differentiator. Understanding where IT fits in and the value it brings is the first step to bridging the divide.

The strength of the Agile methodology is that it brings product owners into the project at a detail level and requires that they are actively involved for the project to be a success. As the project teams are formed leadership should be assigned to the person who will see value from the project, they must be the champion and drive the results, This is often abdicated to the IT team as they understand the systems but this must not be allowed to happen or else the divide will continue. Using an agile methodology the "leader" role is of much less important as decisions are agreed by the team and not dictated by a project manager but the leader helps sets the direction and priority of the deliverables. So having a project leader who understands the system should be the least of the requirements for the role, the most important attribute is the person who is going to live with the product day to day.

Having the product owner lead the team is the first key rule, second is to have the right level of subject matter experts (SMEs) who can be actively involved during prototyping and configuration. This is key so that early decisions can be tested and if wrong refined and retested. Success is generated through small iterations that can can fail fast and reapply lessons learned to get to a solution. Having the right level of engagement and involvement speeds up the iterations as time is not wasted on get the right people to "test" the product at the end.

By having an active product manager and engaged SMEs the responsibility for delivering the project moves out of ITs hands to a joint ownership of the whole project team. Suddenly the finger pointing and washing of hands goes away as everyone is responsible for the delivery. This sounds easy but it often takes a huge culture shift supported by senior management to see these projects not as IT projects but as projects that deliver value to the business. Of course this needs to be more than having a few business people who have time on their hands join a project, this will not make a slight bit of difference. As with many agile initiatives start small, find a sponsor who is open to change, identify a product manager who understands the value of the IT assets, pick an IT team that is secure enough to work closely with the business without feeling threatened. Make the initial project a success and then iterate!

Additional information