“Make it Work Like Our Current System” and Other Requirement Pitfalls

This is the final article in in the series for implementing “Custom Off The Shelf” (COTS) solutions; a follow up to our Buy vs. Build Your Software  and “Off the Shelf” Implementation Pitfalls articles. In this we want to address requirement approaches that are sometimes proposed, but rarely successful in such an implementation. In an […]

Issue Resolution – Celebrate Your Success

This blog is the third in a series of posts designed to help technical leads get over the hurdles that inevitably pop up during any complex implementation; a series that was started by Understanding the Problem and continued in Determining a Solution. With the course set and the implementation of the recommended solution underway, it’s […]

“Off the Shelf” Software Implementation Pitfalls

This is the long-awaiting (or at least long-promised) article on implementing “bought” products; a follow up to our Buy vs. Build Your Software article.  Many large organizations rely heavily on external vendors for large scale software implementations of “Off the Shelf” packages – very frequently modified for competitive advantage and/or to align with internal business […]

Career Paths – Project Management

Career Path for Project Management Roles There are two job descriptions in the project management career path for our IT department.  The entry level position is Project Manager.  This role supports the Director of Information Technology with small project management functions. The next and final level is Senior Project Manager.  This role continues to provide […]

The post Career Paths – Project Management appeared first on Enterprise Architecture in Higher Education.

A Project Portfolio Management Approach

I introduced an approach to project portfolio managment (PPM) to my IT team at the American University of Sharjah.  After 9 months here, I have a real sense that we were doing too many projects for the resources that we had available.   The result of trying to do too much was that our planning […]

The post A Project Portfolio Management Approach appeared first on Enterprise Architecture in Higher Education.

Prioritization tool

  Considering which features to realize should be dependent on time to market for the product and difficulty of realization. Properly used this little tool can help architects balance the organization cash flow. Using this kind of diagraming technique it’s easy to get a comparison overview across many products.    

My First 180 Days as a CIO

Hard to believe that time has gone so quickly in my CIO role.  On March 17, 2013 I have been the Director of Information Technology at the American University of Sharjah in Sharjah, United Arab Emirates for 180 days. It has been a huge change for me especially after spending 20 years at the British Columbia […]

The post My First 180 Days as a CIO appeared first on Enterprise Architecture in Higher Education.

The Art of Accepting Feedback

As practicing solution and enterprise architects we regularly present our work to our stakeholders for feedback. Those stakeholders range from mentors to peers to project teams to executive sponsors. In any and all of those situations, it is important to be able to accept feedback. In some cases the feedback will have been solicited by […]

All Effective Enterprise Architects Are Agile

I explained to one of my clients recently that there is a perception of animosity between the Enterprise Architecture community and the Agile community.  Both sides make assumptions about the other, often assumptions that are simply unfair.  For example, many in the EA community think of “agile practices” as an opportunity to develop software without any architecture at all, while many in the agile software development community think of architecture as one of the “big design up front” guys who oppose their principles and practices.  Of course, it is not difficult to find people who fit those unfair descriptions, but I’d like to point out how these two viewpoints are similar.

I believe that effective Enterprise Architecture must be approached from an agile standpoint. 

First off, what does it mean to be agile?  We can always look to the agile manifesto for some guidance, but more recent publications do a good job of filling in some of the details as well.  I include a number of things in the notion of “being agile.”  These are not just from the agile manifesto, but also Kanban and the Theory of Constraints, Systems Thinking, Six Sigma, Scrum, eXtreme Programming, and value stream analysis.

  • A focus on performing high-value activities, and removing low-value activities.
  • A focus on empowering the people who make things to make decisions about how those things should be made.
  • A focus on developing small increments of actual value on a frequent basis and getting direct feedback on them.
  • A focus on making sure that one thing is “done” before moving to the next, so that we reduce “debt” as we go.
  • A focus on modern practices that remove ‘deployment impedance’ like test driven development and continuous integration.

I follow the terminology of Sam Guckenheimer in calling this the “Agile Consensus.” 

We have to recognize that the “agile consensus” is an approach, not a methodology.  It is a way of thinking about dealing with problems.  More importantly, it is a way for dealing with complex problems.  The diagram below comes from Ken Schwaber (inventor of Scrum) who adapted it from Strategic Management and Organisational Dynamics, by Ralph D. Stacey.

image

When we look at the problems that software is being used to address, and if we look at the process of writing software itself, we have to recognize that both areas of problems typically fall into the category of “complex.”  Not always.  Some software is simply configured and configured simply.  Some problems that software addresses are simple problems.  However, most of the discussions around software development are fueled by people addressing complex problems because that is where most of the software development community works.  It is the bread and butter of software development: solving complex problems in a complex way.

Enterprise architecture also deals with complex problems.  EA models and information are also complex to build and manage.  In this way, EA is very similar to software development.  EA solves complex problems in a complex way.

In order for EA to be effective, it has to use the same mentality as agile software development.

When I speak with enterprise architects who are actually doing the job of EA, big themes quickly arise:

  • do the work that is highly valuable and don’t do the work that the business doesn’t value
  • build consensus where it actually lives, not where the “people from above” believe that it does
  • deliver value quickly and in increments that your stakeholders understand
  • leave your repository in a good state of completeness with all the data that others need to use it
  • build in the deliverable artifacts into the business processes that need it, so that you get immediate feedback

If this looks like the list above, that is intentional.  I am trying to point out that Enterprise Architects use agile ideas, even if they often don’t use the term “agile” to convey the message. 

Why use these techniques?  They work for complex problems. 

Can someone think of a more complex problem than helping to move an organization towards their goals? 

EA addressed complex problems.  Agile thinking helps them to do it.

Lies, Damn Lies, and Traceability

In my last post, Traceability 101, I talked about the essential role traceability plays in the success of a project. By writing business requirements, functional requirements, and then drawing traces between them you can create a traceability matrix that reveals 1) business requirements that are not covered by functional requirements, and 2) out-of-scope functional requirements […]

Everything you’ve read about IT Project Failure is wrong

I did a scan around the web to figure out what many of the leading thinkers were saying about IT project failure and the root causes.  Numbers varied between 20% and 80% of projects failing to deliver on their business case.  The root cause analysis that follows from these failure numbers spends a lot of time looking at the IT project, but most forget to look at the causes of failure that are outside the project’s control.

In the diagram below, the central blue box represents causes of IT project failure that are inside the control of the IT team.  As you can see, there are many more causes of IT project failure that are OUTSIDE that blue box than inside it.  Yet, countless articles have been written on the factors INSIDE the box.  I think it is time we take a slightly wider lens to the problem!

image

The factors outside the project are as important, or more important, than the ones inside the box.  I have worked on many projects over the years, and if I look back at the ones that ended up cancelled or scrapped, the reasons were not ones in the blue box.  They were usually ones from the top box: where the project should not have begun in the way that it did.  Let’s look at these six factors:

  1. Lack of accountability for success – Sometimes, in an organization, an interesting situation will arise.  I call this the “can’t lose” scenario.  In this scenario, the CIO will suggest that the business can benefit by doing some particular initiative, and his or her people will set out to find a business sponsor for the initiative.  In this case, the sponsor will reap the benefits of the initiative, not the CIO.  (Let’s say that the CIO has suggested a Business Intelligence initiative, and signs up the Chief Marketing Officer to sponsor it).  If the project succeeds, the sponsor wins.  If the project fails, the CIO (not the sponsor) loses credibility.  After all, it wasn’t the sponsor’s idea.  The CIO dreamed it up, after all.  In fact, the sponsor may not do any real “sponsoring.”  He may sit in an occasional status meeting and check his e-mail while the program manager he assigned from his team answers questions… and keeps him protected from any blowback.  The sponsor in this case is not accountable for success.  No one is.  The odds of this project succeeding are small.  (Note: a good IT Governance system prevents this condition). 
     
  2. Failure to get buy-in from above – Often, a senior executive will ask his operational leaders to suggest IT projects for the planning cycle.  The executive (let’s say Tina Smith, Vice President of Sales) assumes that the leaders (William, Ashok, and Lee: all three are General Managers) will ask for projects that align to their individual strategic needs.  One of those General Managers, William, decides to create an IT project to implement a SOA service bus.  He wants the bus because he is investing in replacing an application and his IT team tells him that a bus is a good idea.  After all, if everyone in the Sales group uses it, everyone will benefit.  But William doesn’t get Tina Smith’s buy in.  He implements his SOA service bus, but when subsequent IT funding requests come up to move other sales applications over to the bus, his peers Ashok and Lee are not interested.  Their priorities don’t include moving to the bus.  William bought a white elephant.  Because he didn’t get Tina’s buy in, none of his peers will reap the benefits.  Is the SOA bus a failure?  Well… it’s not a success.
     
  3. Misaligned prioritization – Lee James, General Manager of Sales for the Western region of Contoso owns a sales strategy for the enterprise.  The strategy is to make the sales force more productive by moving the company over to a new CRM system.  The CRM system has out-of-the-box support for a long list of reports, but his team tells him that he shouldn’t use those.  Instead, he should put in a Business Intelligence system in the cloud.  Lee wants to trust his team to pick the right solution.  They tell him that the cost of this system is $4 Million over two years.  The company is moving to a new strategy that de-emphasizes the direct sales force.  Instead, the company will be relying on social networking and direct eRetail to make sales.  To make the new strategy work, there are eight projects totally $8 Million that need funding.  There is a competition for dollars in the IT budget.  Lee goes to bat for his $4 Million commitment.  It’s important because “we are already here, so we have to complete the job.”  This is an example of misaligned priority.  The new BI project can be safely cancelled or scaled WAY back to support a strategy elsewhere, but that other strategy doesn’t belong to Lee.  The one that he owns needs money and he’s going to keep fighting to fund it because his boss, Tina Smith, isn’t aware of the tradeoff.  Lee fights, and Contoso loses.  Which project will fail?  Both of them.
     
  4. Slow decision making – This one is related to the other problems in that it is often, but not always, caused by a poor governance system or poor prioritization of the effort.  In this scenario, the team implementing the project needs the sponsor to make a decision, often one that requires consultation with his or her peers or counterparts in another part of the company.  The sponsor may be unwilling, unable, or incapable of having a difficult conversation.  On the other hand, they may be indecisive.  Regardless, this situation can cause serious delays in a project.  For example, Ashwin’s application sends EDI-formatted messages to a health insurance provider.  The provider had indicated that new fields are allowed in the messages that are very valuable to Ashwin’s line of business.  However, he has to upgrade his EDI translation software to get the new fields.  The EDI translation software is also used by the Finance group to send banking transactions.  Ashwin knows that the finance group will get a benefit out of the upgrade and wants them to help cover the costs.  This upgrade will add $25,000 to the cost of his project and he’s on a tight budget.  The software team offers to write a small component that will insert the fields into the data stream, but its complicated and fragile. Ashwin cannot decide if he should ask the finance team for funding or if he should upgrade the software.  The project team cannot proceed without a decision. 
     
  5. Lack of authority to drive change – This one is quite common.  Ashok reports to Tina Smith, VP of Sales for IBuySpy.  He has told her that he wants to take the lead on one of her strategies: to consolidate all of the eCommerce systems in the company to a single outsourced vendor.  Tina things that this will reduce costs all around, and Ashok is happy to take on the challenge.  His business analyst does a survey and it turns out that the services and support team offers customers the right to buy replacement parts online.  In addition, the “outside services” team allows customers to buy a service contract on their own area of the website.  The main sales site, of course, uses a high-volume low-cost vendor that Ashok is comfortable with.  Ashok sets up meetings with the owners of the other applications, but they choose not to provide the needed transaction cost information or the cost estimates of changing their internal systems.  His data is light but he strongly suspects that there is a good business case for switching.  Unfortunately, he doesn’t have the data to prove it.  Without data, the Tina won’t take the case to the CEO to require the other teams to jump onboard.  The strategy fails.  Neither Ashok, nor his manager Tina, have the authority to require their peers to adopt a lower cost system.
     
  6. Lack of influence to rally peers – In many organizations, the prevailing attitude is that the boundary between “centralized” services and “federated” services is intentionally fuzzy.  In these companies, there is no policy that requires a function to be centralized vs. federated.  For example, if a company has ten divisions, three may have their own financial processes, while the other seven share a common finance unit.  The decision to use the central finance unit, or to own a federated unit, can be made and unmade depending on who the leaders of the business are.  (Note: leaders change, and with them, these decisions change as well).  This kind of policy is good for flexibility, but creates both inefficiencies and often, confusion.  This is simply a tradeoff in the design of organizations.  It is neither right nor wrong.  In this environment, any business can create a “centralized” function by convincing more than one business leader to come together to create a shared resource.   The flaw comes when a group wants to create a “centralized” (or simply “shared”) function, but they lack the influence needed to get multiple businesses to join the initiative.  Difficult questions of shared funding can be demotivating, and the political need to create “alliances” can be difficult for junior executives that, in many ways, are competing with one another for the next rung on the career ladder.

 

Each of these conditions has the potential to kill an IT project.  I would suggest that MANY IF NOT MOST of the failures of IT projects can be traced to one or more of these conditions, but these conditions rarely get counted in the statistics for “Causes of IT Project Failure.”  Why?  Because, in most cases, projects that suffer from these conditions are either never funded, or are reworked so that the political problem is simply avoided.  The project business case does not reflect the problem, so the criteria for failure (doesn’t meet the business case) is never met.  Efforts are made to avoid (but not address) the problem before the business case is written!

This is the world of the Enterprise Architect.  These are the kinds of “failure” that fill the eyes and ears of an Enterprise Architect.  If an EA focuses on only these six causes, he or she will deliver real, tangible, and unique value to their enterprise without ever overlapping the roles and responsibilities of an IT architect, business analyst, or technologist.