Staying Relevant for all Things Enterprise IT
The mantra that technology, and therefore Enterprise IT, is constantly changing is a misnomer. It is true, that technology toys (like the iPhone or iPad) change for the better and improve, smart phones data access gets faster, and computer processors are better than previous generations of processors. Yet, enterprise IT really have not changed.
The term “Enterprise IT” can mean anything. Here, it will be defined as IT application systems (be it custom solutions, processing, reporting, data warehousing) used to support business functions.
Enterprise IT has not changed, because a divide between IT and businesses exists in many organizations. For this reasons, many IT projects fail. A case in point is the failure rate of projects as reported by PMI and can be as specific as ERP project implementation failure rates in the last decade.
McKinsey Quarterly published an article in this post – Why business needs should shape IT architecture.
This article inspired me to write about keys to successful project implementation. I struggled many times in the past in trying to determine what was the key ingredient in successfully managing a project. My thought was that communications was the key to implementing successful enterprise IT projects.
That is only one ingredient.
Communications is a key ingredient from a project manager’s perspective. Here is a strict definition of Project Management.
McKinsey Quarterly points to Enterprise architecture management (EAM) as “a framework to manage IT architecture and ensure that both the business and IT are well aligned, aims to restore order to this landscape.”
The approach centres on the role of IT architecture. Architectural design, as the magazine writes, is expressed in a language that may be understood by the business. In effect, the ownership is placed back in the hands of business users.
As a result, the article sites a decrease in time to market for new applications of 50 percent.
The EAM approach uses business domains, domains, and subdomains as the building blocks. For example, an example of domains is client services, product management, HR, and legal. You can infer that this approach identified parts of the system that were core, shared, or quite simply, “other.” The article further classifies “other” as the “customized” application layer.
This approach to managing enterprise IT architecture for projects is not “standard” for those who are trained in general Project Management. So, this is a refreshing viewpoint that I readers ought to investigate further.
More general IT-related entries may be found here.
May 5, 2010 - 8:10 am
Great article . I wish I had something more insightful to see but you have pretty much covered it all here. ThanX
May 7, 2010 - 10:00 am
Chris, you touch on a lot of very interesting points.
The first thing is change, on one hand we recognize that the rate of technological change is accelerating. On the other hand, history repeats itself, there are constants, as you mentioned, for any endeavor to succeed (whether business or marriage or anything else), there must be good communication, but much more, there must be common interest/objectives and a common value proposition or common set of values.
About 20 years ago, I took a seminar and purchased the book “Peopleware ,,,” http://is.gd/bYyBu where the authors took a look at hundreds of software development projects and analyzed why they failed. In over 90% of the cases, the failures were due to people issues, not technological issues. I’m sure that the failure of IT projects would likely have a similar ratio. Lack of business alignment would in this case be classified as a people issue, not a technological issue.
Project Management disciplines also help, but in themselves are not enough to attain a high success ratio.
Clear business objectives help, but also are not enough.
I am not familiar with EAM, but I have studied ITIL http://is.gd/bYzsO ; a framework for IT Service Management that was developed by the British government to manage all of its IT service development and deployment and management, it is also being used by the Canadian government for similar purposes and is also being adopted by some Fortune 500 organizations. To generalize, any successful endeavor must have a repeatable process that all the stakeholders understand and buy into. For small organizations this can be totally ad hoc (although that is not scalable) and for large organizations, these processes can be home grown or imported from process organizations. Good process definition and management is then necessary for repeatable success, but in itself is not enough.
I believe to achieve relevance, success, satisfaction, the key ingredient is good leadership. Good leaders learn from the past and have a clear vision for where they want take an organization; they clearly communicate and win over the stakeholders to that vision; they select the right people for the right responsibilities; they make sure the right processes are in place and that they are properly managed; and many more things. That is why nations have heads of state; armies have generals; businesses have CEO’s. Some look like successes in the short term, some are popular and some unpopular; ultimately history judges their effectiveness by the long term benefits of their leadership.
Makes you wonder why history is not part of computer science or engineering curriculum, eh?