Thursday, November 26, 2009

Circling the dragon

This is a phrase I use frequently when I am trying to find a stubborn or elusive problem.  I am not always sure everyone understands the statement.  The short definition of the phrase is to keep chipping away on the periphery issues to get to the root (dragon) of the issue.  It also means sometimes you cannot solve the problem in one step and you have to plan your way to resolution.

I will explore both options in this post.

The graphic below shows the dragon in the midst of the OODA loop.  This is by design.  The approach to basic and pragmatic trouble shooting is to follow the loop.

Getting to the dragon by process of elimination

This approach is used when you are not entirely sure of what or where the dragon is.  An analogy would be of a dragon slayer going on a quest to find the dragon.  The dragon slayer would follow the trail and the evidence till the dragon was found. 

You need to really focus on the OODA loop here.  The first step is to clearly observe all the elements not just one the ones you are comfortable with.  Look at it from different angles and from different perspectives.  In the orientation phase of your observation you are likely seeing just a symptom of the deeper problem.  If you could see the root problem (dragon) you would take a different path to solution.  For this discussion we are going to state you are just seeing the symptom. 

Once you have oriented yourself to the observation you need to list the options (decisions) you have.  Play it out in your head what happens with this test or with this action.  Visualize the process.  This will give you what you expect to learn or gain from the exercise.  This is where I see most trouble shooters fail.  They tend to hack away at things and in doing so miss the relevant.  They also, end up wasting time and more importantly they tend to add to the problem. 

The approach of elimination is just that.  Break down the issues in systematic and measured steps.  You should have an expected result from the effort.  Sometimes the effort is to just prove what it is not.  This is OK, sometimes you need to validate the known so you can find the unknown.  As Spock use to say in Star Trek, “if you eliminate the possible all that is left is the impossible”.  There is a lot of wisdom in that.  All too often we jump on the obvious, only to find out it did not solve the problem and we have learned little from the exercise.  By taking a step back before we jump in, we can see if jumping in is even worthwhile.

Once you have played out the possible decisions you need to act on them.  I am amazed at how many people freeze here.  They have a solid basis for their approach, it is based on solid observation and alignment (orientation) with the decisions and yet they do not act.  My favourite clue for this, becomes the accountability blame game.  It manifests itself in statements like “I do not have authority to do this or I sent an email and no one responded”.  This shows lack of ownership and commitment.  If you do not act then how do you expect to solve the problem.  Hiding behind email shows lack of personal accountability and leadership.

Once you act on your decision then you need to start all over again.  What did your action do to change the situation at all?  Even a nothing change is telling you something.  If nothing happens, you may have to undo your action.  If it did in fact change something what did it change.  The exercise of “what is it telling me?” is critical in the orientation step of the repeatable loop.  Force yourself to dig deeper and in doing so you will be given different decisions to draw from.  Once a list of decisions is made act on your plan.  Once the action is done, start all over again.  Are you sensing a theme yet?

Eventually, even if it is just shear will power, you will find the dragon and reduced it to its smallest elements.  The result is the dragon is gone.  Now like all dragon slayers you have to go and find a new one to battle.  How you defeated this dragon now becomes knowledge you can use for your next encounter.

Slaying the Dragon in steps

When you know what the dragon is and where the dragon can be found you may need to take several steps to get to it.  If so, then it becomes all about the planning and execution of the plan.  It is the deeper, more mature, application of the OODA loop.  When you have found the root cause and you know it cannot be slain in one cut then you need to plan and prepare for its exorcism.  To be fair, of late, this is lacking in so many firms and people in  our industry.  We have become obsessed with the tools and the analytics but little work is actually done solving the problem.  We have better diagnostic tools then we ever have had and yet we still are falling behind in solving issues.  This is not unique to the information technology field, all one has to do is look at our health care and you will see we are more focused on the problem then we are on the solution.
In building your plan you need to break it down into its appropriate steps.  Once each step is defined you need to mentally validate that the steps are in the correct order and what is the expected outcome of each step. 

Doing so is critical to the OODA loop execution.
So once you have made your plan, you observe the environment.  This can be done by doing a baseline test and measurement.  You then orient yourself to the observations.  Has this baseline highlighted anything or shown a pattern you were unaware of?  Note these observations for future reference.  Make a decision as to the plan execution.  Execute (Act) on the first step of the plan.

Once the plan is in motion, observe what is happening.  Orient yourself to your expected outcomes.  Are the expected outcomes being realized?  If not, what have you found out?  Do you need to change the plan?  Once you have made up your mind then act on your decisions and the next step of the plan.  Start the loop again at the observe step. 

Doing so will quickly, and hopefully, predictably slay the dragon.  The key is that you must be adaptable to what you are seeing and you must be able to orient yourself to your observations.  Your decisions need to be based on what you see and what the context is of what you saw.  Lastly, without action you become the victim of inertia and in problem solving inertia or inaction is the enemy. 

In conclusion

Problem solving is about bringing solutions to bear.  There are many who can write emails and memos on the problems facing us all.  The real challenge is to bring solutions so the problem are resolved.  To the naysayers who wax poetic “there will always be dragons”, I say to them clearly and with purpose, “Lead, follow or get out of the way”.

Sunday, October 18, 2009

The people side of problem solving

As of late the amount of work hitting our team has been staggering. The initial response by the team is that we are overworked. Fair enough….. or is it?

I have always struggled with this comment. My approach is and has always been, if you do it right and pay attention then you rarely have to go back and fix it. If this is a truism then the work you are doing is moving you forward not holding you back.

Since not many people give this argument much thought or at least my current team doesn’t, I thought I would take this blog to express my position or stance.

To solve a problem you have to first acknowledge there is a problem. Seems simple but it is not that simple based on the observations I make on a regular basis. Frequently, I have been known to say in passing “see a problem, fix a problem”. Typically this is something as simple as fixing a colleagues tangled phone cord when you borrow their phone. A simple gesture, but one I consistently do, just because. Other simple ones like filling the paper tray of a printer you walked by because you heard the error tones. Holding the door open for someone whose hands are full should not be something that has to be “memo’d” to be done.

Yet, as I look around I see most of us plodding along and doing as we are told. This is a huge burden for the person that is responsible for telling us work needs to be done. I can’t remember a time when my boss had to explicitly  tell me to do work. Sure, we have meetings to discuss priorities and new projects, but I would be insulted if he had to tell me do something that is clearly in my implicit mandate. An example is doing the annual Disaster Recover Plan. His job is ask what occurred, or to make a decision on if we are going to spend more money on it. He does have to “tell” me to get it done. That is my responsibility and accountability. It makes his life easier and it clears up our meetings for more strategic endeavours.

We are in the midst of a very large multi-vendor phone upgrade. It involves the lion’s share of our users and will impact the entire enterprise. It has been 10 months in the planning and will be executed over 5 weeks. We have fundamentally altered the way we use telephony. By all measures this is the single biggest project our infrastructure group as ever worked on. Saying this, my immediate expectation of my group is to be focused and to think of things that are not so obvious. Put yourself in the chair of the users.

For months I have been listening to the push backs and complaints of my team of how much work they are doing for preparation. I keep reminding them that this large effort will reduce our overall efforts in out years. The smarter ones get this, but the average ones do not. This is why I am writing this post.

Our cabling person is driving 2 hours to visit one of our closest sites to prep for the phone changes. Phones use cables, cable people put in the cable, putting in cables requires tools, cable person should be automatically bringing tools. NOT….. He wasn’t told to, and is very comfortable is stating this. Sadly, this is not such an uncommon event. I have been speaking to my other colleagues and they are experiencing the same type of behaviour. My simple response is “until there is a penalty there will be no change”. Yes I know this sounds harsh and the softer side of me says “you get more with honey then with vinegar”. But what do you do if the honey is not working? Common Human Resource procedure has the manager doing way too much work to get so little in return. So I continue to reward the good behaviour, and then acknowledge the bad behaviour. It makes for a long day at times and many visits to the human resource department.

As a person you have to want to fix the problem that is on the people side of the equation. If you or your team is not personally engaged to fix the problem, you likely will be dealing with the issue for a long time to come. However, if you are capable of creating a culture where your team cares about their job and their relationship with the larger firm, then you will be able to solve the problem right the first time.

pig and chicken

The above picture is one of my favourites. The saying goes something like this: “Who is more committed to the breakfast meal, the chicken or the pig?”. The answer is the pig, for it has to give up its life to provide the bacon for breakfast. As of late, I am finding way too many chicken’s laying the low fat, low content eggs and spouting off about how much work they have done. Whereas, the pig cannot say anything for it is too busy being the meal.

Be a real person when solving a problem, and remember that you are likely solving it for someone else. Also, it is not important who fixed it or who solved it. What is important is that it was fixed respectfully and effectively. Spread the praise of others and do not be afraid to call out the naysayers. If the naysayers want a voice, let it be the voice of self-defence instead of their smug offensive.

Thursday, September 3, 2009

My New Toy

Well I finally did it.  I supported the economy in my own little way.  I bought a brand new, gas guzzling, kick ass 4X4 truck. I am so happy.  Can you feel the testosterone?

Mine of course is better than this picture. The picture is the same colour but mine has the soft tonneau cover, bug deflectors and the window vent visors.  Are you impressed?


my toy

Wednesday, September 2, 2009

Where are “U” in the user experience?

What part of U 

This post is a result of the last few days and the constant reminding I have I had to give me team.  In the midst of a technical system failure it becomes so easy to lose track of the users, your role and the role of the people you are speaking to.  From the people, processes and tools approach I adhere to this post is clearly dealing with people issues. These issues are a direct reflection of how they interact with the tools and the processes.  I am a true believer in everyone is accountable for their actions and interactions with others.

Know your role


If you are the support person and you are being asked by your superior a question then please do a baseline assessment.  The mental assessment should go something like this “who are they?”, “what level of knowledge do they have?”, “How much context do I have to provide before I give the deeper answer?”.  It should not be “WHY are they asking”.  This is insulting to the person asking the question.  If your superior has asked a question please answer it.  If you want to have an esoteric mind conversation on the “why” and “conspiracy theories” do it on your own time.  For the most part when someone asks a question they really want an answer. If this is the typical courtesy “how are you today?” then by all means feel free to lie.  But when they ask a question of you because you are the support person, then answer with facts and stay on point.

If your role is support then please provide some.  Remember that you are being asked for your advice and consul to fix a problem.  It may not be your fault or it may be.  That should not affect the facts. Also get over yourself.  Just because you know more then the person who asked the question does not mean you know it all.  You may be surprised what the user and your superior know that could make you look silly if they choose to.  Do not give them a reason to exercise that option.

Treat both the user and your superiors with respect.  You do not have to like them to respect them.  This is a great position to take with anyone you work with, play with or live with.

Speak in the language and context of the person you are speaking to.  If the end user is from warehousing don’t be throwing acronyms their way or speak in geek speak.  Try to use their language.  If you do not know and you want to be successful then you should start to ask questions of them to educate you on the problem in their language.  Picture yourself in a foreign land with a foreign language and you need to get some directions.  Break the communications down to that level. They are likely the master’s of their domain and you can learn something from them instead of telling them things that make your world easier.

End user

If you are an end user and there has been a system failure you have a role to play as well.  It is a very important role.  You are the recipient of the direct pain of not having your system working.  You need to provide more insight then “it doesn’t work”.  Or my personal favourite, “I can’t get my work done and it’s IT’s fault”.  It may be the Information technology’s department fault or it may be what you the end user did.  Either way we need each other to get the problem resolved.  Please keep the drama for your friends in the lunch room and not for the ones who are trying to help.

Please pay attention to what you do when you are using a system and/or a process.  I know us IT folks like to poke fun at the dumb users but hey users get paid to do a job too and that job is rarely a direct result of the technology.  Sometimes it is and then I personally get frustrated when for example a programmer who uses a computer all day to do their job has to have the infrastructure group setup the new monitors or keyboards.  Come on .. . .  get real.  This is tantamount to driving a car and not knowing how to put fuel in it.  Yes I know they exist out there and they are also breeding but someone needs to educate them or better yet slap them.


If you are the leader please pay attention.  First, I did not use the word manager because that is completely different and was explained in a different post.  The leader has to assess all the facts and from all the players.  Do not get caught in the drama.  Stick to the facts, assess what and who is impacted.  Find out “what changed?”.  Have all parties quantify their statements.  I use the line “what evidence do you have to support your position?”  I get amazing results from this approach.  First it disarms those who want to finger point and it also forces the team to stay on facts and not conjecture.  Following my fact based strategy will save many cycles and reduce stress.

Prove and/or disprove all the theories coming at you.  Your role is to direct the flow of information and more importantly to get the decisions made.  Sometimes these decisions are not made by you but you need to get these decisions made by the correct people. 

You also need to ensure that all parties are not crossing boundaries.  This is very common in large projects and  when people start to influence peddle like a bunch of politicians at voting time.

Be confident of your role and do not let others dissuade you from your role.  It is not good for the team or for you.


Each and everyone of us has a role to play and the role changes as the situation changes.  Sometimes you are the leader, sometimes you the end user and other times you are the support person.

Each and every time you enter a new situation take the time to observe the roles of others and more importantly yourself.  This goes for when we are in informal situations as well.  The best leaders have proven they were also excellent followers. 

Monday, August 31, 2009

Sample argument for a Blade Center

Here is a sample discussion paper I wrote to assist a First Nation Community in evaluating a blade center approach to infrastructure.  The name of the community and identifying details have been altered or removed.

What the following post highlights is that the model changes with blades and virtualization to the positive.  However, an organization’s thinking must change to achieve these benefits.


The Community administration’s is looking at strategies to upgrade their server infrastructure.


There are currently 11 servers within the community at different stages of their lifecycle. Many are end of life and present a critical risk in the event of failure. The traditional method of creating a business case for each server is both time consuming and may be preventing future opportunities. This briefing note will attempt to demonstrate another alternative.

How does it work today?

In today’s environment when a server becomes end of life the organization is faced with several challenges. The first challenge is to understand the role of the server. Is the role of the server mission critical? Some of the servers today are considered mission critical. The more mission critical a server is the shorter its outages can be. These servers perform functions like email, accounting, grades, Firewall, printing, file sharing etc. Each and every one has its role to play and it may or may not be able to be offline. Only the organization can make that assessment.

Once this assessment is done, then the organization has to determine how big and expandable does the new server have to be to last until that platform is end of life. The recommended recycle time for critical servers is three years. If you follow this approach the first years of the server implementation the server is running well below optimum, the second year it starts to realize full performance and somewhere in its third year the server will start to become strained from overuse. This is a typical scenario and is repeated for each and every server. These ebbs and flows are constant in the industry.

To address this static hardware replacement strategy the industry is now deploying what is called blade centers. These blade centers take the best of today’s hardware and packages them so they can fulfill the needs of many servers on one hardware configuration. This virtualization of physical servers to many logical servers is well demonstrated and proven in the industry. The technology has been proven and it is being used right here on Manitoulin Island at Manitoulin Transport. They were able to consolidate over 100 pieces of equipment down to 10 pieces of equipment while at the same time expanding their services offerings.

Costing Sample

The following table demonstrate the costing model difference between upgrading 11 servers independently verses using one blade center. The blade center described is capable of running 18 servers of the type and model being utilized by the community currently. I have chosen 18 due to the fact more servers are actually being recommended by all the major vendors today. It will also allow the community to build testing environments without having to purchase new hardware.

blade costs

As you can see the second year of the model the cost structure dramatically switches in the favour of blade centers. If you factor in additional servers then the case for blade center is proven sooner. The third and out years are even more favourable to blade centers.

Benefits of Blade Centers

  1. Centralized control and management
  2. Cost savings
  3. Centralized Backup
  4. Back and recovery per server is consistent and resilient
  5. Annual incremental increases verses sporadic larger capital costs.
  6. Autonomous building of servers
  7. Integrated security
  8. Improved network performance and resilience
  9. Reduced support costs
  10. Small form factor
  11. Reduced energy costs
  12. Reduced heating and air conditioning requirements
  13. Industry adopted
  14. Many vendors to support the platform and its implementations
  15. Increase the number of servers with minimal or no additional costs
  16. Increased flexibility for your technology rollouts
  17. Hardware independence from your operating systems. Bigger benefit in the Microsoft world.

Burdens of Blade Centers

  1. New skills are required to maintain the platform
  2. Software to build the platform will need to be purchased
  3. Migration project will need to be undertaken to port the existing 11 servers to a common platform
  4. Organizational policy change to support central housing and shared resources
  5. Governance structure for support and backup rotations
  6. Annual operational dollars will need to allocated to sustain the platform


The cost of hardware is plummeting but the challenge of effective use of hardware is ongoing. By adopting a blade center strategy, the community can reduce costs, increase effectiveness and provide a long term platform for the entire community. Each of the current 11 servers is important and their ongoing support and functions are critical to the overall community. A proactive and long term view to their deployment will have a positive impact for the community.

Next Steps

  1. Agree to the strategy
  2. Build a requirements list for the platform
  3. Build a RFP
  4. Source the platform
  5. Build the migration plan
  6. Perform the migration

Monday, August 17, 2009

The challenge of Voice over IP

There are lots of discussions regarding Voice over IP (VoIP).  They typically are centered on the technical merits or shortcomings.  This post will attempt to address some of these issues but more importantly address the business discussions that should be transpiring.

First, my biggest pet peeve is for the vast majority of the naysayers who claim with great flair and passion that “VoIP is not ready for the real world”.  Ok, check the sources of these claims.  Most likely is the the big telecomm groups. Why?  Simple, they are trying to keep as much money in their pockets as long as possible.

Every technology has growing pains, the telco’s have had a hundred years to better the experience. Recent failures of the big telcos show they didn’t see the real business problem but are still bragging on the technical wonders of what is in their labs. 

This graphic shows the timeline from the old copper days, to digital phone (the said saviour of the business) to Internet Protocol (IP) phones.


The point here is that there has been a path to something different over time and with increased functions.

The large phone carriers have been doing VoIP at their interconnection points since the late 90s.  These are the same carriers that say VoIP is not ready.   My challenge to them has always been, then what are you doing to get it ready?  Their users have spoken and answered in droves by saying “not much”.

I personally have been doing VoIP at the trunk level for my enterprise phone switches since 1999 over Framerelay, yes Framerelay.  So much for the engineering specifications of today’s massive network requirements.  Which leads me to the real challenge of the convergence.

If VoIP is going to work it has to travel on a good data network.  Seems simple but here is where the real cultures clash.  The clash is not in technology but in approaches to solving issues.  The 100 plus years experience of telephone thinking is move slow (read glacier speed) and over build.  The premise always was, we have lots of money and time.  Along with this the customers really had no choice.  If you wanted voice mail and auto attendants the choices were limiting, confusing and very expensive.  This voice culture rewards safety and engineering prowess.  In the traditional phone world the engineer dictates the experience, hence the horrible user interaction points.  The only saving grace was it worked predictably and reliably.

The culture of the data teams is get it in and fix it later.  This is a plaque that is ruining the industry.  Poor network design along with sloppy implementation coupled with cavalier change management policies is their legacy.  This culture leads to some of the vast security breaches that occur today.  The network needs to be designed and implemented properly to really gain the value of VoIP.  Some of benefits of the data network engineers is one of adaptation and creativity.  This is a good trait to have as long as it is well managed and lead.  In this new world the network is king so let’s not make the village idiot the king.

On the same note, let’s not make the telco trolls the masters of all.  This is way too dangerous and counter productive.

The Internet and the internet protocols are here to stay.  Many good people have built worthy networks capable of running VoIP simply and effectively.  These people have used the true value of voice engineering design principals with the creative approaches and techniques of the data network arena.

The business case for VoIP is simple, reduce the moving parts and players and you gain the competitive advantage.  It is easier to find network experts than phone experts.  The technology being created for the VoIP space is being done by creative people solving real business problem.  They are also using modern business models that are more cost effective and give the businesses real options to solving a vast range of business issues.

We have currently converted 5 of our major phone sites to VoIP in support of 600 users.  Phone updates are done by the PC techs using the same tools they use to setup a new Windows users.  The days of the black arts being managed by the Merlins are coming to an end and that is a good thing.

The kingdom should be managed by the king on behalf of the kingdom for the benefit of all.  VoIP is an effective business tool to get there.  Yes there will be scary witches, there always are when you are implementing big change.  The alternative is to continue to pay too much, get too little and be locked into old rigid thinking.   Modern companies have fought through the technical issues and now are reaping the benefits of mobility and true business control of their phone infrastructure to gain business advantage.

Some benefits to the business are;

  • Ease of Moves, add, changes (MAC)
    • Can be done by PC Techs
  • Mobility of workers without support calls
    • Worker can change offices without have to call for new cabling or setup
  • Everything is a data drop CAT5e and CAT6
    • No more dual copper connections
      • voice CAT3
      • data CAT5e and CAT6
  • lower licensing
  • Cost based on users not systems and users
  • More competitors for different options within same environment
    • phone systems
    • voice mail
    • call recording
    • reporting
    • phone sets
  • incremental user costs for new users
    • Can purchase as needed instead of in bulk
  • Session Initiated Protocol (SIP) trunking for dial tone
    • Very inexpensive and very reliable regardless of what you hear from your vendors.  Talk to actual users of it
    • Significant business continuity benefits and toll reduction over traditional PRI setups

Some draw backs and cautions to VoIP

  • The data network must be checked for compliance
    • DO NOT underestimate this.  Just because it is working does not make it workable for VoIP
  • Tough to find a vendor that is good at both voice and data
  • Tough to get the voice and data teams to behave nicely together
    • expect causalities if you have mature teams.  This is not always a bad thing
    • They need to learn from each other without coming to an impasse
  • Watch out for the hidden licenses.  Read the fine print and ask lots of questions.
  • Every thing is server based and with all servers then need to be maintained in a proactive way.
  • Make sure your core data network is near any voice recording software.  Voice recording in the new VoIP world is very easy and let unmonitored will kill your data network with traffic.
  • Make sure you are solving business problems when you purchase some of the optional offerings.  This is where their money grabs come from.  Do not be afraid of mixing your vendors.  Is this new world is it very easy to do because of established standards.

Test from Windows Live Writer

This is test to see how Windows Live Writer works.


  • This is me when I prep for my Sensei
  • Be afraid but do it anyway
  • Train today to better then you were yesterday to defeat the enemy of tomorrow

I have to admit the tool is really kewl. Setup is a little odd and it does not read the Internet settings from the O/S or IE. For a Microsoft product that is odd.

I will be using this tool on a regular basis. Thanks Frank for showing it to me.

Thursday, August 13, 2009

Thoughts on operating systems

Here is a link to a friend of mine. His thoughts on operating systems is well worth the read.

It is brilliant in its clarity even if its implementation is hard work. Doing things right is rarely easy.

Monday, July 6, 2009

Solution Lifecycle and accountability

The above graphic demonstrates the influence and accountability for the opportunity, project and production methodologies as described in previous posts. It is important to note that the influenence area is real and should be addressed as an influence and not necessarily permission. By this I mean, it is important to inform the influencing areas and to get their input, however, not all influencers are decision makers. The seasoned Information Technology professional will work the organization to deliver the overall goals and to get influencer buy in.

This is a short post for the graphics speaks, hopefully, the remaining elements. I may expand in future posts by the blogger, ME, is tired now.

Opportunity Management


Opportunity Management is becoming a growing issue for modern IT shops. Why? Increased scrutiny of IT project resource utilization, and the subsequent rise of the portfolio approach to project management.

  • Many IT projects are fraught with perceived cost and time overruns. The days of "show me the money" and you get your project are coming to an end.
  • Portfolio management's primary focus is to manage opportunities, projects, and systems. By engaging at the business level early, you can gain an appreciation for the business drivers and the proposed solution design constraints.

This paper will focus on the processes required to manage opportunities that come to or from the Information Technology (IT) group. Opportunity Management moves you away from the "order taker" role and toward the "trusted advisor" role. This move is becoming manifest with organizations challenging their technical teams to deliver business value, not just cost containment. In this scenario, IT doesn't drive the car – it supplies the car. IT is a service-enabler, and Opportunity Management supports the concept of IT being a service-enabler for the business rather than just being a cost center. A cost containment attitude equates to a "no can do" shop mentality, which is not good for your team and limits your ability to get funding for your much needed projects.

Adopting an Opportunity Management methodology is also a good mechanism to work more effectively with the business units, to gain buy-in, and to understand business processes from their perspectives. Respecting each business unit's core competencies, issues, concerns and viewpoint goes a long way toward making any opportunity successful. You may not always understand or even like a given business unit, but it is imperative that you respect them. Doing so will return respect to your area of technology expertise. It will also give them the chance to witness the potential of technology as it relates to enhancing their business processes.

The methodology explained in this paper supports both waterfall and Rapid Application Development (RAD), though this method is especially attuned to RAD. Adopt the mantra "start small, think big, scale fast." By using this approach, you will be able to respond quickly when the organization is ready to scale solutions beyond their original implementations.

This methodology can be used for both short- and long-term engagements. The stages may look onerous upon first glance, but you will find for smaller projects you only need to confirm details at a certain stages. It remains an excellent checklist to ensure you have covered all the bases, regardless of the size of the opportunity it is managing. As you perform more of these engagements, you will find that many of them take on a similar form and you can reuse patterns of not only previous designs, but also of documentation.

The graphic above demonstrates the flow of opportunity Management

Stage 0 – Opportunity Identification

IT is constantly inundated with requests for changes and the setting of priorities, so this step should look familiar to many in the IT field.


The main focus of this step is to give the opportunity a name and a shape. "What is the big idea?" is a phrase frequently used in this phase of the discussion. Typically, in larger projects and larger organizations, this opportunity may have been defined in the normal business planning process.

The "elevator speech" is all that is needed to identify the opportunity. An elevator speech is a description of an opportunity that can be explained to a potential sponsor in the time it takes to ride an elevator from the ground floor to the boss's floor. There is no need at this stage to get into final costing or even resource planning. A discussion of "What is the big idea?" and "Why is it being asked for?" is the focus. All too often, IT people start thinking about the "How?" and forget what is driving the "Why?" If the sponsor is clear on why this is important, then assembling the how is less likely to get bogged down, because the focus remains clear.

It is important to log every opportunity in a tracking system. The logging mechanism can be a spreadsheet, database, Web site, or even Notepad. It can be formal or informal, but it is critical that it is logged. For example, you could use your service desk to log all activities regardless if they are issues, changes, or projects. Such an approach makes life easier when resource planning and, once captured, it is guaranteed that all users and stakeholders can more readily follow successful processes.


The qualification step focuses on placing the opportunity against the overall strategic business plan and moving priority projects forward, while at the same time redistributing other projects and priorities as required. This cannot be done in isolation; and it is not the role of IT to set priorities, but rather to act on business priorities. By providing trusted advice back to the organization, the IT group is enabling the organization to make better decisions with more and better information. And IT has to eliminate the "sell from the install". During a "sell" engagement everyone is positive and wants to make and opportunity work. This is not a bad thing; however, the qualification step is intended to bring the "install" piece into focus. Issues, such as cost, time, and scope have to be mentioned here to validate the opportunity.

Qualification commences once the sponsor has clearly identified the business drivers and a further investigation has become warranted. Determining the requirement for further investigation can be the tricky part. For the sponsor, an investigation is always warranted and he/she usually can't believe you are not jumping all over the identified opportunity. This is where you get to earn your money – this is your opportunity to work with the sponsor to explain the process, and help everyone understand where their opportunity fits within the context of other organizational initiatives. By working with the sponsor, you can help him/her articulate the opportunity using a pragmatic approach.

This process is meant to put all identified opportunities on the same footing and to align similar projects. It is always amazing how similar "different" departmental needs are when you look for common ground. Organizations that take a step back to align similar projects effectively have a better chance of stopping rogue projects and IT teams, and avoiding duplicated and wasted efforts. But by no means do you make this approach a "boiling of the ocean" exercise, because too much time focusing on strategic alignment prevents achieving valuable short-term gains that can move the organization forward and satisfy the legitimate desire users have to have their needs met.

Adopt a "make !T work" attitude (no, this is not a typo). The philosophy behind this is to make the IT components work for you, and to avoid those components becoming barriers to success. Your job is to align your IT services with opportunities realistically, so your organization can make an informed decision of the validity of the opportunity.

Priority Matrix

Using the priority matrix as defined in a previous post will ensure proper alignment and qualification.

Stage 0 Deliverables

  • Entry of the opportunity into a tracking system.
  • Identification of the opportunity's sponsors and business drivers.

Stage 0 Outcomes

  • Opportunity identified and entered into tracking system.

Stage 0 Duration

  • One or two engagements, which could mean as little as one e-mail or as much as two meetings.

Stage 1 – Positioning

This is the first formal stage in the opportunity management process. The goal of the Positioning stage is to clearly articulate the vision of the opportunity and its inherent execution requirements. This stage usually requires several workshops, especially for larger projects. As with most first steps, getting it right is vital. All other stages are based on the work of this stage. Without buy-in at this stage, the remaining steps becoming increasingly difficult to execute.

Vision Statement

The vision statement must answer the question, "Where you are going?" The vision statement encompasses the guiding statements of what the opportunity must accomplish. Many firms get hung up on this and create long, drawn out statements that obscure focus and lose value. The vision statement focuses on where you are going, not on how you plan on getting there.

An example of a simple but effective vision statement is, "The solution will provide Internet access to our customers, when they want it and how they want." The statement is clean, clear and is the rod against which the solution will have to be measured. If the solution proposed cannot be accessed off-hours, or cannot allow customer changes, then the opportunity cannot be successful. It also demonstrates a first cut at the solution scope. This proposed solution does not include detailed input from partners or other stakeholders, and must be flexible enough to envelop that input without becoming diffuse.

Mission Statement

The mission statement answers how you are planning on getting to your solution. It is a set of clear directions that are specific to the proposed solution. An example of a mission statement from the preceding vision statement would be, "The solution will use the existing resources to develop an in-house Web-based solution for customer self-service." The key is to keep the mission statement as focused as the vision statement.

Business Drivers

Business drivers become a further articulation of why you are proposing the opportunity. It represents the business you are in and why this opportunity is important. The business drivers can be such things as increased revenue, more access, reduction of costs, or response to competitive forces. Either way, you need to explain why this opportunity is an opportunity – if it isn't an opportunity, it may just be a good idea with no substance.

Key Performance Indicators

Too many projects get funding and have resources assigned when they have no measurable performance indicators. How can the project ever close if you do not know when you have arrived? The performance indicators can be such things as the completion of one month-end, a percent of usage measure, or a simple thing like turning down the old system. By stating a performance indicator you have a natural closing point and a positive approach to the project.

Stating measurable success criteria will allow further steps to contain scope. If the scope is for customers only, and a measure of success is to have 5% of your customers using the Web site within one year, when you have reached the 5% mark then the solution has completed a key performance indictor. The key is that these indicators must be measurable, or they fail the test as indicators of anything at all.

Another consideration is that IT projects are always plagued with perceived overruns and dragging-on of issues. By stating performance indicators up front you are engaging the business units to define, in their terms, what represents success. You must get the business units to sign off on this component, as this will ensure their buy-in as the opportunity turns into a solution and then into a production system. At all stages, the business unit, again in its native terminology, must understand that the IT team is working with it to solve its issues. By engaging them in this process early, it also makes it easier to get the business units to perform and commit to testing at the testing stage.


The dreaded governance component is like death and taxes – it is inevitable. The opportunity must be have an owner and a sponsor. Sometimes, in larger projects, the owner and sponsor are two different groups. Without clear ownership and sponsorship, a project risks being tagged as an IT project; and as soon as the IT group gets involved the tendency for most business units becomes to defer responsibility and accountability to the IT group. This allows units to spread the guilt if the opportunity isn't accepted, and it is the quickest way to achieve failure. We in the IT field have enough of our own projects – we don't need to get saddled with those from other business units.

The business units know their area and hopefully your team knows IT. They come up with the important "Why," and you have to supply the "How." The governance stage provides for an excellent matching of players between the IT team and the business units. This way both groups know their roles and the components for which they are responsible. It is also an excellent way to measure the level of commitment by the business unit. Are they warm, cold, or very hot toward this opportunity? When you start hearing, "I am not very technical, so shouldn't you lead this?" run for the hills – it is an indication of a lack of commitment from the business unit. You are there to provide trusted advice to the organization, not to be the business sponsor. Now is your time to shine and explain your role.

Stage 1 Deliverables

  • Vision statement.
  • Mission.
  • Governance.
  • Business drivers.
  • Draft definitions for success.
  • Input into the solution outline.

Stage 1 Outcomes

  • Position paper that is no larger than 15 pages.

Stage 1 Duration

  • One week.

Stage 2 – Validate Business Needs

This area focuses on further refining the business input, its operating procedures, and its opportunity assumptions. The existing and proposed business models must be defined for any proposed solution since the proposed solution must be able to support the activities of the business unit.

Traditionally, feasibility studies can cover up to and including this stage. All the work done here is to further define and clearly state what currently occurs and how the business unit would like proceed. By knowing these guidelines, the technical team can always check to ensure the solution does not deviate from stated objectives.

Core Business

The core business definition is used to validate the overall objectives of any opportunity. If the opportunity does not complement or satisfy the core business, then it may need to be reconsidered. The focus of these core statements is critical to maintaining the integrity of the solution since, should that focus change over time, the solution will be affected. This is recognition that the solution must be designed to be as dynamic and flexible as necessary to manage changes over time.

It never ceases to amaze the number of groups that cannot clearly articulate the business they are in. Many a time I have heard from the accounting department in a manufacturing company that their departmental business is making widgets. Yes, they are critical to the success of the making of widgets; however, what business is the accounting department in? When I hear phrases like, "we are in the business of collecting, collating and deciphering the business transactions for the organization," I am confident the process is going to have a successful outcome. Success is not always measured by the opportunity being realized; many times it is that the sponsors have accepted the opportunity, worked the process, and that they trust the IT department is giving unbiased support for all elements of the organization.


Programs are the major methods for delivery of the core business functions, and can either be formal or informal. Continuing the accounting example above, some programs offered by the accounting department could be Accounts Payables and Accounts Receivables.

Programs are how the business unit is broken down to functionally manage their services. Not having an articulation of the business and their programs will make any solution definition incomplete. Every step of the process must be able answer the questions: is it supporting the business and, by definition, is it helping in defined program areas? This is a good acid test to ensure the opportunity is being supported and sponsored by the correct group. Many an opportunity, when it gets into the hands of the IT department, turns into an IT project. This is because the opportunity team is not ensuring the core business and program areas are driving the project. Business solutions should not be lead by IT teams. Having said this, it is imperative that IT representation is present in order to ensure all elements of the organization are covered by any technical solution proposed.


Services deliver value to members of a target group. Typically, this is where the program areas interact with other areas of the organization or customer base. Again, following the above example, the Accounts Payable program area may have a service provision for printing Vendor checks.

Typically, an opportunity is addressing key service areas. This exercise should clearly identify the services the proposed solution is addressing. The service areas, at times, may need to add, change, or delete service components. For example, automating approvals and check printing may have a direct impact on an existing check-printing service. This services definition is especially important in any outsourcing engagement opportunity. By not clearly articulating the as-is services, the new services may overlook key areas that cannot be performed by the new service, and adoption of a final solution will naturally fail under that oversight.

Client Profiles and Scenarios

Specific client areas that will benefit from the opportunity are defined. By breaking down the clients into groups, the business unit will be able to define common wants and needs. This client profiling is used to build scenarios.

Scenarios are structured walkthroughs of the proposed solution. Once the profiles and scenario are defined, a series of business unit engagements can be used to build the use cases. Use cases are nothing more than documents in clear business language to define the specific steps of any given user scenario. If you spend the time in the scenario definition, then the facilitation of the use cases is infinitely easier. (Do not allow the technical team to hijack these meetings. The goal of the scenario workshops is not to start coding, but to garner the spirit of the opportunity and its touch-points with the clients and, ultimately, the solution.

The use cases should focus on the actors, events, and triggers that happen. In simple terms, the actors are the internal or external users of the system; the events are the functions to be performed; and the trigger is what caused the function to commence. Do not get carried away with defining all the business rules, but focus instead on the interaction between actors, events, and business units.

Environmental Scan

Before you engage too far it is always best to get an assessment of what solutions already exist, so best practices and best-of-breed solutions should be researched. The usual magazines, trade papers, and technology Web sites are excellent resources. Today, it is becoming easier to find off-the-shelf products for many solutions.

Colleagues are also an excellent place to source ideas. Learn from the ones who have walked the path first. Look for lessons learned and comparative analysis. Don't forget to weigh your needs against the features and do not get lured into features you don't need and possibly will never use.

The key is to look at things from many perspectives, and weigh existing solutions against the maturity model of your organization. You may be able to find the best-of-breed solution from a given product domain, but is your organization able to understand it and use it? Beginning with a smaller solution to get the organization prepared for a more formal discipline is a good approach. Many of the steps described here are not wasted when putting in a smaller, less function-rich solution. Many purists may disagree with this, but too many large projects cannot get out of the starting gate because the organization cannot get its head wrapped around the larger, more complex system. But when this "start small" approach is taken, it is imperative that the organization realizes those solutions are transitional solutions and elements of the final solution. Not all of this interim solution may be used in the final solution, but nor is it a "throw-away" diversion.

Stage 2 Deliverables

  • Definitions for core business, programs, and services.
  • Validate the opportunity goals.
  • Further define the business drivers.
  • Define the governance model.
  • Environmental scan.
  • Input into the solution outline.

Stage 2 Outcomes

  • Use cases profile definitions and for more traditional approaches the feasibility study.

Stage 2 Duration

  • One to two weeks.

Stage 3 – High Level Scenarios

This is the first stage in which technology is introduced to demonstrate the opportunity. The mockups are a low risk approach to visually presenting the options. These mockups are not complete solutions and are not intended to be production ready.

This stage is often used to introduce new concepts. Consider the "7 times 7 different ways" theory, which states that to have people understand a new idea will take seven presentations using seven different approaches. In IT today, one of our many challenges is educating our user community on the realm of the possible. Today e-mail is pervasive and you don't have to explain its concepts. However, at one time we spent a great deal of time explaining e-mail as a generic idea. Some of the new challenges are Instant Messaging, document management, and Web portals. To be blunt, most users do not know what they do not know. In older, mature groups they need to a have common point of reference for new ideas. The mockup allows the IT department to show different approaches of tackling the opportunity as they understand the business needs and drivers.

The mockup can be a slide show presentation, skeleton application that demonstrates workflow, or vendor product demonstrations. This bidirectional dialogue between business sponsors and the IT team is invaluable for nailing down the scope and buy-in of the business unit. Most business units like to be involved in this stage and find this part of the process rewarding, so let them play in the sandbox, but make sure you let them know when recess is over. The goal is to get their input in a non-technical environment where they can see and touch elements of the opportunity.

Though mockups, the business unit also gets to see tangible proof that the IT team understood the previous steps and the business problem that generated the opportunity. Changes to the solution, scope and design are accomplished easily here and should be encouraged. Some IT professionals have a hard time with this step, because they want to deliver a more workable mockup. Be careful of this desire – it will waste valuable time and resources. The users are going to make changes, so get used to it, but do not forget to document the change requests. Welcome to the iterative world.

Stage 3 Deliverables

  • Documented customer profiles.
  • Documented use cases.
  • Mockups.
  • Input into the solution outline.

Stage 3 Outcomes

  • Solution shortlist and/or workable prototype to be further developed.

Stage 3 Duration

  • One to two weeks.

Stage 4 – Technology Alignment

After the mockups, the technology team retreats to their development area and designs a system. This is easier said than done, but if it was easy, someone else would have done it already. At each step of the design process, the IT project lead has to ensure the vision, business, program, and service area's goals and objectives are respected.

The design should include logical and physical architectures, and in a more formal organization you would get architecture sign off and guidance as well.

One area that is usually forgotten at this juncture is the support model. This area requires special care. Many systems are not evaluated thoroughly, and will come back to haunt you in the post-implementation stage.

Work with your user community and your service desk (if you have one) early to get a feel for the non-functional requirements of your proposed solution. Will it need "24x7" support, or is "business hours" support good enough?

Compare the solution to your existing infrastructure. Can you support this new solution? Do you have the capacity, skill and/or resources? This is the time to get those determinations documented and clarified.

Compare your solution to your technology blueprint. Are you duplicating functions you may already have? Is there opportunity to consolidate solutions at the technical layers? An example of this might be the sharing of a Web application server rather than implementing a secondary provider solution.

Once the deliverables are completed, a final workshop is provided for the business unit, so that the IT team can demonstrate the solution. Do yourself a favor and make sure you keep the technical language to a minimum. I have seen too many projects where the technical group is so enamored with their solution they can't help themselves, and drown the presentation in technicalities. All of sudden the client asks, "What about this or that?" and you can hear a pin drop for the sudden silence.

This is the final opportunity for the client group to get their message across as to what they need and how the solution must look, so be respectful of both the technical team and the business unit. Again, changes here are not serious because you are still refining the solutions.

Once the user area has signed off on the technical design, you can proceed to costing and a final proposed-solution design.

Stage 4 Deliverables

  • Updated customer profiles.
  • Updated use cases.
  • Support model.
  • Mockups.
  • Non-functional requirements definitions.
  • Logical architecture.
  • Physical architecture.
  • Input into the solution outline.

Stage 4 Outcomes

  • Tangible, workable solution architectures.

Stage 4 Duration

  • Two to four weeks.

Stage 5 – Proposed Solution and Costing

After stage 4, the final touches can be made to the proposed solution. By now the functional and non-functional requirements have been agreed and negotiations can commence for costing and component manifesting.

A high-level work plan is established to create milestones and costing containers. These costing containers may include such things as training, implementation, transition, cutover, and/or build costs. At this stage, the costs are used for budgetary purposes, and final negotiations should always bring your costs down at the purchase stage. Many groups get themselves into trouble by negotiating feverously at this stage only to loose leverage due to the time it will take to get final approval.

Work should also be done at this stage to tighten up the component elements of your solution. Tasks should be given to the IT team in respect to further definitions and clarity on development and/or interfacing costs. When trying to interface a new system into an existing infrastructure, make sure you have estimated the learning curve component for your team to acclimate to the new system's parameters and architectures. This is not the time to throw stones at the new kid, for we all live in the glass house. Use the "Improvise, Adapt, Overcome" mantra to get your team focused on getting the solution to work. Everybody is encouraged to make it work instead of finding every possible reason why it can't.

Also, nail down support costs for the initial rollout and ongoing support. Don't forget to clarify how the solution will be maintained. If is maintained by the vendor, how does the vendor expect to support you? Is the solution a mission-critical solution? Is the vendor aware how its solution is going to be implemented?

Stage 5 Deliverables

  • Revised functional requirements.
  • Revised non-functional requirements.
  • Update to logical architecture.
  • Update to physical architecture.
  • Solution costing.
  • Support model and costing.
  • Input into the solution outline.

Stage 5 Outcomes

  • Rough draft of the solution outline and very high level costs (+/- 25%).

Stage 5 Duration

  • One to two weeks.

Stage 6 – Implementation Planning

This is where the rubber hits the road. All the work until now, for the most part, has been open-ended with no firm commitments on dates and deliverables. After stage 5, the client and you are committed for the implementation plan.

What the business unit wants to know is, "How long is it going to take and when will we get the nod?" This answer has to be sensitive to organizational approval schedules, other projects, resource constraints, and operational concerns.

The implementation project plan might include the following milestones for a development opportunity:

  • Deploy and release to production plan.
  • High level test plan – do not assume the user knows what or how to test.
  • Procurement and setup timelines.
  • Marketing communications plan – it is very important to get the word out on the positives of the opportunity.
  • Infrastructure updates and configuration changes.

Stage 6 Deliverables

  • Project plan.
  • High-level costing.
  • Communication plan.
  • Input into the solution outline.

Stage 6 Outcomes

  • Workable project plan and costing figures for approvals.

Stage 6 Duration

  • Two to four weeks.

Stage 7 – Solution Outline

The solution outline is the culmination of all the previous steps. It is a technical document that will be the main resource for the solution after funding has been approved. Many organizations will get the business units to sign off on this document, but most users do not know what they are signing, so don't put too much weight on their signatures. Do, however, review the document with them to ensure you have captured the business drivers and guiding principles of the opportunity.

The important thing to remember is that the documents will contain all the relevant technical information for the proposed opportunity. Depending on the scale and scope of the solution, this document can be large and not a pretty read, but by culling this document you can build the requirements for the solution and for any Requests for Proposal (RFPs) that may need to be created as a result of this opportunity getting funded. It will become an invaluable resource for your technical team even if it becomes a shelf-filler for your business units.

Your solution outline may contain some, all, or even more than the following items:

  • Introduction.
  • Business scope.
  • Core businesses and services.
  • Mission statement and guiding principals. Clearly state the guiding principles in the solution outline. This will ensure all players understand the overall guidelines of the solution being proposed.
    • Core business.
    • Programs.
    • Services.
    • Types of individuals and organizations.
    • Client needs.
    • Goals.
    • Business drivers.
    • Architecture overview – introduction.
    • Architecture overview – enterprise view.
    • User groups and delivery channels.
    • Business services.
    • Resources.
    • Architecture overview – components view.
    • Presentation services.
    • Architecture overview – software view.
    • Architecture overview – IT system view.
    • Logical technical architecture.
    • Architecture overview – physical view.
  • Non-functional (operational) requirements – Do not overlook the importance of getting in writing some of the non-functional constraints.
  • IT standards – It is always good to state the baseline for which the solution must adhere to. This will give valuable insight into why certain technical decisions where made long after the opportunity has passed and the designers have moved on.

Stage 7 Deliverables

  • Revised functional requirements.
  • Revised non-functional requirements.
  • Update to logical architecture.
  • Update to physical architecture.
  • Solution costing;
  • Support model and costing.
  • Final report back on solution to business area.

Stage 7 Outcomes

  • Final report on solution outline and high level costs (+/- 10%).

Stage 7 Duration

  • One to two weeks.

Stage 8 – Business Plan/Case

Where the solution outline addresses the technical problems and opportunities, the business case addresses the business problems and opportunities. The business case has very little technical information in it and is written to be read by the business decision-makers. The main focus of this document is to state the business opportunity with its associated costs and benefits.

It is imperative to include the business unit in the creation of this document. They have to not only buy-in, but must also contribute to the end result. The organization will be using this document as the core document to make its decisions, so it must be written in common business language and any technical information should be filtered for readability. You do not want the organization to mistake this opportunity as a technical project, and remember that even technical opportunities must drive the business forward.

A sample table of contents of a business case is:

  • Background.
  • Guiding principles.
  • Solution.
  • Software.
  • Technology/hardware.
  • Network.
  • Cost summary.
  • Benefit summary.
  • Conclusion.

Stage 8 Deliverables

  • Business case.
  • Revised costs.

Stage 8 Outcomes

  • Business case.

Stage 8 Duration

  • One to two weeks.

Stage 9 – Funding Approval

The "hurry up and wait" game begins here. All the effort, time, money, and resources are now on hold until you get the nod. If this project is high profile and important you may be working the back room to sell the opportunity before the formal approval process commences, so you want to make sure the elevator speech is being worked at all levels.

Stage 9 Deliverables

  • None – trust the process.

Stage 9 Outcomes

  • Funding approval or a "go/no go" decisions.

Stage 9 Duration

  • Dependent on how your organization approves opportunities.

Stage 10 – Implementation

It has been correctly said that you should be careful what you wish for, because you may just get it. The fun is over when the project has been approved, because now your team has to deliver the promise. The main source document is the solution outline, and depending on the time lapse between its initial creation and your approval to implement you will have to update the numbers and project plan accordingly.

It is important you get sign-off on all changes to the solution outline and business case prior to implementing the previously agreed plan. The line "Don't confuse the sell with the install" comes back again to haunt. The sell cycle is always fraught with positive statements and "don't worry" attitudes. However, once the contract is being presented, the install side of the house arrives to take all the fun and money away. This is also a good time to get the vendors to commit to their schedules and resources as were agreed to in previous steps.

Stage 10 Deliverables

  • The solution as agreed to.
  • Execution of the project plan.
  • Execution of the communications plan.

Stage 10 Outcomes

  • Commencement of proposed solution.

Stage 10 Duration

  • Dependent on implementation schedule as defined in stage 6.


These steps, at first blush, may appear too complicated for most IT groups. However, upon review you will find you have been doing most of these steps all along. This methodology was meant as an "aide de memoir" to ensure your opportunities are given every chance to succeed, and for you to gain valuable input on why the business units are looking for your team's help.

This methodology has proven very successful for both small and large projects. It can span from one week to many months, depending on complexity and scope. After the first few formal uses of this methodology, user groups will grow to understand why previous IT projects failed. One of the major reasons they fail is a basic failure to speak the same language across boundaries within and without the organization, and this approach rectifies that problem by its adherence to a well-founded process.

Being involved in the opportunity stage is new to most IT groups. They are used to users coming up with requests and then being tasked to complete them. This methodology puts you in the trusted-advisor role within your organization, where you will become part of the decision making process. You will be providing the organization business-value through your input and pragmatic approach. The goal is for them to succeed, because when they succeed your IT group will be validated.

Some organizations have swat teams for opportunity development. These teams consist of Web design, graphic design, infrastructure support, business analysis, telecommunications, and customer support. It sounds impressive, but for some opportunities all these roles and more are needed to prove or disprove the opportunity's viability. The bottom line is an opportunity team is a small team that is able to be creative and drive the business value forward.

The risk of not getting involved at the opportunity level reduces the IT group to order takers. By being an order taker, you are bound to the business area's comprehension of the overall business needs and your unique requirements of trying to keep their house of cards from collapsing. As the competitive forces increase and the user community gets more knowledgeable about IT, the ability to manage opportunities will become paramount. Most IT groups are feeling the pinch now. The wave is coming, and it is better to learn to surf then to be swept up by it.

Priority Matrix

Over the next few posts I am going to focus on getting the priority quantified, justified and aligned. This is both a formal and informal process and the Information Technology professional has to ensure that the large list of projects are properly dealt with. All to often we get transfixed by the projects we want to work on or the last one in the door. Either of these conditions can be deadly for the overall effectiveness of your team.

Priority Matrix

Using the priority matrix will give the organization a visual perspective of where their priorities align. On a regular basis, opportunities should be placed on the matrix for comparisons and synergies. What was deferred last time may be ready for action now, especially if your identification process has made a continued to effort to a build common technological framework for delivering business value.

The axis and quadrants of this matrix represent a powerful tool for qualifying opportunities.

Ease of Implementation

How difficult will it be to implement the opportunity? Do you have the correct skills? Is the organization ready? Are there obstacles in the way of success? Can success be measured? These are some of the critical questions that need to be answered before you extend too many resources to the development of the opportunity.

Social/Economic Value

Too many opportunities are measured on pure economic value. This method has proven to be successful in building an organization, but in a highly competitive marketplace more factors need to be considered than just the old standbys. Many opportunities have a social benefit that is difficult to measure – for example, social impact is often overlooked when qualifying employee portals and intranets. Many opportunities are lost when faced with the concept "if it isn't broke, don't fix it." Successful organizations take the time to quantify all benefits, and to build environments that are moving the whole organization forward rather than just handling the issues relating to sales, manufacturing, and/or finance. The entire benefits of an opportunity should be investigated when bringing new opportunities forward. The challenge is to quantify the benefits in the context of business value.
Even more critical to qualifying opportunities effectively is to understand the quadrants of the matrix in relation to the potential for positive business impact.


This quadrant of the matrix is for those projects that are less difficult to implement, but have a lower Social/Economic Value. Basically, this quadrant contains the "nice to have," but not the "need to have" opportunities and benefits. Timing is everything and the projects in this quadrant generally spark up good positive interest, but the organization isn't prepared to implement them now. Typically, these projects will see the light of day, but just not in this round of approvals.

Do Now

This quadrant speaks volumes for those opportunities that are easy to implement and have high Social/Economic Value. The low-hanging fruit analogy works well here. These opportunities should be moved forward and funded to advance the organization. The value to the organization can be immediately achieved and the organization is comfortable with the overall fit. The projects align well with any strategic plan or roadmap. These projects were typically once in the plan quadrant, and have since become practical.


When the value is high, but the implementation becomes more difficult, it may be best to review and build a funding proposal. Most new opportunities that require the organization to break new ground will tend to fall into this category. Also, these opportunities tend to require more detail before the decision-makers are comfortable giving the nod to proceed. Overall, these are good opportunities. A fit is recognized, but the comfort level by all the parties is not there. By providing more detail, the organization will be able to make a more informed decision. With opportunities under review, it's a good idea to go back to the business drivers and substantiate the findings, and also go back to the technical options to see if adjustments are needed.


The Wait quadrant is for those opportunities that are deemed difficult to implement, and where strong value statements are difficult to quantify. These opportunities are typically beyond the current scope and understanding of the organization. Opportunities in this quadrant typically need to have a communications or an awareness plan developed before they can be advanced.

Tuesday, June 30, 2009

Enterprise Architecture

The art and science of creation

Today, the word architecture in the Information Technology arena is not always used in its correct context. As one of the silver backs I can remember when we used the word engineer as a freely as we use architect today. We had customer engineers, solution engineers, hardware engineers etc…. Some uses were correct and others were very loose interpretations of the term. Today we have information architects, solutions architects, network architects, voice architects and the likes of usability architects. Again, some correct, others, well, just good old marketing.

I personally take architecture very seriously.

The Webster’s dictionary that I possess at home states the following:

Architecture – The art or science of building; that branch of the fine arts which has for its object the production of edifices pleasing to a cultivated and artistic taste; construction.

How real is this? Architecture is the marrying of art and science. The production and building of edifices (technology) that is pleasing. Pleasing becomes the operative word here. Just because something is built does not mean it is architecture. It just means it was built.

Architecture is like so many other borrowed terms we use in Information Technology, and made our own. This one in particular is of special interest to me because I take it so seriously from its purest beginnings and meanings. We stand on the shoulders of giants rings so true in this arena.

Some of my previous posts talked of the IT Stack and its importance for sound design. Enterprise architecture follows many of the same truisms. The IT Stack becomes what a draftsperson is to an architect. The architect has a vision and translates it into real-world designs. The architect then works with the draftspeople to iron out the real world forces. When we were all called engineers, I baulked because too many engineers only know the known and do not push the limits. The architect starts with art in mind and then transfers it to real engineering problems to be solved.

The graphic above demonstrates the 4 key domains for enterprise architecture. Some enterprises will have more domains and that is just further fragmentation of the arts and sciences. The department of defence has taken a much deeper view, but if you were to step back the 4 main domains this post will encompass the others in some form or other.

The graphic has the business domain as its center and I believe it is the lynch pin that binds the other three. With the business domain of “why”, the other domains of “how” become support players to the main event. Even the best historical architectures had an underlining purpose. These edifices of wonder were able to solve the need with special designs. The pyramids, the coliseums, the churches and the grand bridges that have stood the test of time have also stood the test of good taste. I remember standing in the Saint Michel castle in France and witnessing the formidable architecture that was over 1000 years old. The basement did not leak, the walls were not cracked and the roofs have sustained the mighty gales of the English Channel. In its 1000 plus history the walled city had never been breached and the trained eye could see the advancement of technology in the buildings while never giving way to the sheer beauty of its architecture.

In modern times we have such wonders. Time will tell which ones were true to real world realities and have lasting artistic value.

The information technology craft is new and as such is prone to flux and at times chaos. Now is the time to gain back some creditability to move us forward. Many believe the pace of change has been too fast. I could not disagree more. I feel we have been hindered by technology business models that have rewarded the quick and easy and not the long, difficult, right way.

I was speaking to our owner regarding the “cloud.” Our owner is a self made multi-millionaire and a companion of the order of Canada. He has prided himself on honest, pragmatic business. He has been rewarded for his principals and he is also the holder of several key transportation patents for his forward-thinking designs. By his own admission he knows nothing of computers. After about a 10 minute explanation from me comparing the “cloud” to 3rd party logistics companies he started to understand. That analogy is the best I could come up with where you do not own the assets but leverage them. My owner had a pregnant pause for about 20 seconds. This is a long time for a man of his drive and passion. His response was short and very direct. The reply was “what took so long.” For him it was so clear, yet, we as an industry have not been able to exploit it and move it forward yet. The answer to that riddle took a little longer. Over several beers he came to realize that the technology sector is not rewarding leaders of technology but rather managers of business. The business model is sound but the debates over what is or what is not the “cloud” is preventing us from moving forward as a whole. This is not good business and even worse technology. His response was, you had better agree on that you need a road and that everyone has to be on the same side of the road. He brought our problem back to his transportation world.

This is a long pre-amble to state that without a real business reason any architecture is strained to deliver value beyond its artistic impression.

Business Architecture

This is the core domain and it answers the biggest question and that is the “why”. The next area of concern for this domain is what, who, where, when and which information is relevant. The process thinking person is well suited here. The business domain is about making the logical connection between business information and the processes that drives it and relies on it. A good business architecture model will drive all the other models and be used as the referential checkpoint for all the other domains.

Be careful of the process purist. These individuals tend to pave the cow path and have data needs that will strain good data governance and control. The process should solve the business needs in the fewest possible steps, in the most secure way, with sufficient oversight to be managed and to be improved. All architecture domains need to be built to be built upon.

The strategic business view needs to be broken down into tactical components and then into operational elements.

The business domain will map the people, their processes, and the tools required to complete the business requirement. I am a visual person, so I will draw many process and mind maps to isolate the patterns for improvement and critical success. The information going back to the organization must be presented in the form the business can understand. The artefacts also have to serve as the core building blocks for the other domains. Constant checkpoints from the other domains have to be made to ensure the business domain is adhered.

Technical Architecture

Some groups will call this domain the infrastructure domain. I am part of that group. This domain manages and controls the hardware and software of the organization. Along with this it will adopt secure methods for all other elements of the solutions.

The biggest and most valuable artefact from the technical architecture is the blueprint for the functional and non-functional requirements. I pay special heed to the non-functional requirements, for these are the ones that tend to get overlooked and cause the greatest strain during implementation.

This domain also has a large role to play on cost minimization, technology blueprint adherence and the proper implementation of standards. A good implementation of the technical architecture will become the building blocks for other domains and other business solutions. This domain should focus on flexibility and reusability. The patterns derived from this domain are almost always used for other solutions. This domain also provides a strong blueprint that can be used for all following elements, especially security.

Solution Architecture

Solution Architecture is the glue that binds the data models to the technical models to deliver the business model. Some groups will call this domain the application domain. If you are new to an organization and their enterprise architecture group, then make sure you get their taxonomy clear. Some groups can be very particular on this.

Solution architecture starts to make patterns from the business model, to feed the data model, and will be supported by the technical model. The focus here should be on component modeling and the carving down of major functions into smaller more reusable elements and modules. Strong adherence to security, interface design (internal and external), data connectors, messaging, auditing, logging and version control become paramount. The project manager and the business sponsors need to conform to the business model and the non-functional and functional requirements. Scope creep can be a real issue here and controls need to be used to keep the team focused.

This domain will also be faced with the greatest iterative steps and the greatest use of lifecycle management. The users will be playing in this backyard with little or no expertise and it becomes paramount that the solution architecture stays true to the business architecture. When there is confusion, a checkpoint must go back the original model to ensure the business needs are being met. At times this domain can get enamoured with scientific or artistic discoveries. The architect is required to keep the final vision in focus and not the current unforeseen discovery. This is a real discipline and the best solution architects have a strong eye towards delivery rather than discovery.

Data Architecture

This is likely the oldest of the disciplines and is the genesis of many other methodologies. It is computer science 101 and is the most abused of the disciplines. The advent of spreadsheets and personal databases has muddied this craft. There are many who think they understand data models but the ones who really do get frustrated by the poor data models and database implementations of the others. Another issue that arises is the forced use of old techniques when newer more effective approaches are warranted. Modern databases support auto indexing and the old technique of composite keys only burden the systems for downstream business analystics.

The conflict has always been present between the data purists and the process purists. The fact remains they must be in balance and work complimentary.

Data should be modeled to reflect the process’s use of the data and yet still be able to convert the data into information. I have seen overburdened data models that span thousands of tables where similar applications patterns have used 100 of tables. The pure data architect can justify both but only the enterprise architect can validate which ones solve present problems.

Modern databases and database options need to be exploited in a positive proactive way. Privacy and security issues can be enhanced within this domain for a more robust overall solution.

I really enjoy seeing the application domain come to life within the data model. Many of the business model patterns can be tested and vetted with good data architecture. For in the end if it is not stored it does not exist for the other domains in a complete enterprise world. I know some knowledge management folks have just cringed. Data architecture takes into account all structured and unstructured data to complete the information picture. Once these patterns are complete and available they become a source of knowledge.

In conclusion

Without architecture we have form without function. With good architecture we have function with form that is pleasing. We have all witnessed good architecture even though we may not recognize it as architecture. To some architects that is the highest compliment. I am in that camp. When it works in its simplistic form to solve the most complex of problem, the Architect has successfully created art from the sciences.

An architect’s vision without execution is just a drawing. With execution come future patterns to be used by others to further the craft.