Can we finally dump the stove-pipe approach for projects?

Written by on January 26, 2015 in Guest Blog with 0 Comments

Stove pipeThe telecommunications industry has probably invested more than most in information technology supporting areas such as operational and administrative automation.

The overarching approach that all industries have historically taken, and still do in acquiring information technology, is project-oriented selection and deployment based on:

  • Functional Requirements gathering
  • Design
  • Implementation
  • Testing
  • Launch
  • Operation
  • Change management

The functional requirements gathering is, by and large, done vertically and stove-piped by subject. Once the requirements are ‘set in stone’ the project team designs how the information/data should be stored and in what ‘format’ it should be transported/processed in order for the functions to be carried out, for example, by an employee. The employee captures this information to fulfill a purpose before re-entering it with added information into another specialized system that was developed with exactly the same approach, but with different data store ‘format.’ As each process is governed by the data it moves, each of the processes also differ.

Getting confused? Not surprising as the systems are acquired to support a vertical function and not with the view to optimize interaction horizontally between the elements that organizations are made up of.

Am I suggestion we have done it all wrong in the past?

Absolutely not!

Systems have been and are being deployed to automate the tasks (read process) contained to a functional area and/or a department. That optimization is limited to vertical scope and provides limited possibilities with a horizontal scope. Many suppliers have acquired companies that broaden their products or solution portfolio but many have also taken a ‘suite’ approach by pre integrating the portfolio into a solutions suite. However, this does not necessarily address the fundamental approach to how the application or solution was developed in the first place.

We have experienced a tremendous evolution in packet-switched networks, software and solutions paving the way for social media, mobility applications and solutions, speed to built data sets for correlation and cognitive analytics and cloud environments (SMAC). Is it now the time to view technology as an integral part of Organization Development and add the discipline of specifying Business Capabilities requirements as a dimension?

If the answer is yes. We simply cannot continue on the journey of acquiring technology on a traditional vertical, and project oriented approach.

I am not suggesting that the project orientation as described above is irrelevant, no not all. However, I am suggesting that a business dimension and an approach to capturing business requirements be added and in sequence ahead of the traditional issues.

Many would claim that this is exactly what is being done. I would suggest that, while requirements gathering is being perceived as coming from the business it is stove-piped and functionally contained in nature by system design being based on traditional HLD and LLD to ensure that the stove-piped requirements are being delivered.

Capturing and defining business capabilities requirements is horizontal and across functions and departments and horizontally channels such that the equivalent of HLD and LLD should be based on reusability. This will require that processes and data formatting are outcomes of business capabilities as opposed to functional requirements.

The sequence will change significantly:

  1. Vision
  2. Business Capabilities requirements and KPIs
  3. Specify task based (process) framework (eTOM)
  4. Sequence the tasks (Business oriented RACI)
  5. Information modeling (organization based HLD and LLD) technical process KPIs
  6. Functional requirements specification
  7. Measurements architecture

The objective will be to deploy technology to provide or optimize the interactions between physical and logical elements of the business architecture and secure value to the market as opposed to optimizing the transportation of data supporting a function or department providing value to only one function within an organization.

Tags: ,

Cato Rasmussen

About the Author

About the Author: Cato is an industry veteran and Subject Matter Expert bridging Business Architecture and Support Architecture with more than two decades hands on leadership and management experience performing complex Business Solutions project. Cato also regularly speaks at industry events. He has experience from working with vendors, service providers, management-for-hire and consulting. .

Subscribe

If you enjoyed this article, subscribe now to receive more just like it.

Subscribe via RSS Feed

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Top
%d bloggers like this: