In the Field with our Experts

Every Story Has a Beginning, a Middle, and an End

By Mary Anne Hopper, Senior Consultant

When not at work, I enjoy racing sailboats - sometimes day racing and sometimes offshore racing.  Last year while racing from San Diego, CA to Puerto Vallarta, Mexico, we spent a considerable amount of time drifting off of Cabo San Lucas in absolutely no wind.   In the middle of the night with no wind, conversation tends to drift to stories amongst the team on watch.  Call it a lack of sleep but some of my stories made complete sense to me but not to my two watch-mates.  So they told me, “Mary Anne, every story has a beginning, a middle, and an end – now why don’t you start over from the beginning?” 

That line has become somewhat of a joke since that day and night spent off Cabo.   But, one of the interesting places it plays in my mind is the BI Requirements process.   That process can be broken down into three steps – business, data, and functional requirements.  A beginning, a middle, and an end.   Starting at the beginning with business requirements sets the stage for what business questions need to be answered ensuring value is delivered.  Data requirements can be gathered to support those business questions.  In the end, that functional requirements can detail how to access that data. 

Oftentimes, I see clients start with a set of functional requirements with no idea of whether or not they can be delivered with available data or what business questions they will answer.   This approach can take the project down one of two paths.  The first is back-tracking back through the requirements process that inevitably takes the project team longer to deliver because they start over with each step backwards.   The other path delivers the functional requirement but only with work-arounds (logic built into reporting, extra spreadsheets, new desktop applications, and so on), also a costly alternative when others try to support or extend functionality.  Neither of these approaches deliver the needed business value with the agility required.So when you’re planning your next BI deliverable, remember that every story has a beginning, middle and an end.  Start at the beginning with the business requirement, work forward to the middle data requirements and then the functional requirement at the end and you’ll enjoy the success of a story well told.

photo by Gabriel Villena via Flickr Creative Commons License

---

Mary Anne has 15 years of experience as a data management professional in all aspects of successful delivery of data solutions to support business needs.  She has worked in the capacity of both project manager and business analyst to lead business and technical project teams through data warehouse/data mart implementation, data integration, tool selection and implementation, and process automation projects.

The Natural Order of Things

By Dave Gilbert, Vice President of Field Services

Recently, it seems that every conversation with prospective clients at some point degenerates into an exploration of how much things can be “parallelized.” I suspect that this is being driven by two primary opposing phenomena: (1) a backlog of BI needs caused by the economic stall, along with monumental budget pressures; and (2) the hyper-speed of new competitive business pressures. While I am a huge proponent of iterative and parallel development efforts, forcing unnatural acts in planning a BI initiative can be a slippery slope when taken too far.

I am an extremely amateur woodworker in my spare time, and this discussion reminds me of a lesson that I learned the hard way – more than once. A few years ago, I decided to build some bookshelves for my home office. Being a planner by nature, I spent sufficient time drawing and designing how I wanted my bookshelves to look. I measured books, knickknacks, and various other things that I wanted either functionally or on display (I suppose you could call those non-functional requirements). I drove to my local lumber yard and picked out some really nice hardwoods and hauled them into my shop. I then spent many delightful hours cutting, sanding, shaping, and staining the various components of my shelves. Because I had to build some jigs to gain the effects I wanted for my shelves, it was much more efficient to cut and route them all in succession before moving on to other components of my design.

Somewhere along the way, my wife (perhaps the most important requirements stakeholder) poked her head into my shop and noticed that the elaborate hardware I bought was functional -- but “ugly” -- and she would much prefer recessed hardware that would be hidden from view. Being all about user satisfaction, off to the lumber yard I went. Unfortunately, this seemingly minor requirements change left my shelves an inch shorter than required and sent me into a redesign cycle which never really translated from paper plan to end product.

The lesson that I learned the hard way – other than the obvious one about gathering all my requirements upfront and getting signoff –- was that by attempting to gain efficiencies in my cutting, shaping, and finishing process, I lost the opportunity for learning through practical experience with my end product, ended up expending more energy, and had considerable cost overruns. Similarly, attempting to put unnatural parallel paths too early in a BI planning exercise can eliminate valuable learning opportunities for the design and development teams, and forces rework on multiple work products - instead of just fully rationalizing your design patterns, making sure they are complete, and then using those to componentize and parallelize your work. It often takes a BI development team one or two cycles of development and testing to get their design patterns fully fleshed out and capture some of the more subtle requirements. Parallel efforts prior to the opportunity for this bottom-up learning only open the door for multiple rework paths, cost overruns and project risks.

As one client has described to me, they are in a continual prototyping mode, but they never get to the “sausage factory.” What they mean by that is that every project is handled as a one-off, and iteratively developed until it is ready for production. But they never capitalize on the benefit of their experiences by operationalizing their processes and then componentizing the workstreams into parallel efforts. Every organization is looking for the magic of the sausage factory, but this requires the discipline to put repeatable processes in place and not to force unnatural evolution prior to its time.

Photo by antwerpenR via Flickr.

---

Dave Gilbert is responsible for managing Baseline’s consulting teams and ensuring consistent high quality project execution to support our clients’ business needs. Dave brings over 20 years of IT system and data warehouse project management experience, deploying systems for both global 1000 and smaller e-business clients domestically and abroad. He has assembled and led multi-national development teams to deliver complex, scalable, analytic solutions that have assisted clients in establishing competitive superiority.

BI and Data Warehousing, and the Role of Business Analyst

By Steven Bebout, Senior Consultant

When I tell people what I do for a living, their eyes typically glaze over.  I am a business analyst with an area of expertise in the DW/BI warehouse space.  When asked to elaborate, my story changes depending upon the industry, current state of the client, politics, budget, priorities within an organization, the client’s history with past data warehousing efforts, etc…

Fundamental responsibilities include: liaison between the business and technology team.  I gather data analytic specific  business requirements; making sure that the data is there to support the requirements, ensure that the preliminary conceptual data models  validate business scenarios, and work closely with testing teams to make sure that the requirements are met.  Gathering thorough business and data requirements leaves the DW more robust and flexible as users further define their needs (especially reporting needs).

I’d like to provide the analogy of building a foundation for a house; a house needs a foundation to shoulder its considerable weight, provide a flat and level base for construction and separate wood-based materials from contact with the ground, which would otherwise cause rot and allow termite infestation.  This analogy aligns itself well to a data warehousing project.

The business analyst provides the foundation for the data warehousing project.  They shoulder the weight of understanding and identifying data and process deficiencies as you are doing the DW/BI analysis; serving as a business-oriented project resource.  In some instances, they may have a systems orientation but this is not an expectation of the business analyst’s knowledge set.

The business needs of the organization are identified by interviewing the key stakeholders.  You interview IT to determine technical feasibility, not business needs.  IT doesn’t define business needs; they only tell you if it can be done and what it will cost.  You take that information back to the business and let them decide if they want to pay for it. Identifying these business needs helps to develop the design needs of the data warehouse; missing or misinterpreting the needs creates ‘infestations’ as described in the housing analogy. 

It has been my experience that the business analyst is the right hand and often assists the project manager throughout the project.  Knowing the foundation of the project and utilizing their client facing skills provides the project manager confidence that in their absence, the business analyst can attend meetings and speak knowledgably on their behalf.

The most successful DW/BI projects I have been involved in are ones where the business analyst is gleaning the user's wants and needs for the business requirements and the data architect/modeler is analyzing the data sources, underlying processes and data quality aspects.  Together they work to construct a business-driven and data-driven conceptual and logical model (and also a dimensional and star-schema model if appropriate).  A broader combination of efforts includes working with the development team to discern the functional and non-functional requirements for the reporting or analytic deliverables and the physical model (normalized or multi-dimensional as appropriate).

I realize that some people are capable of fulfilling both roles (business analyst and data modeler), and certainly on smaller project might be called upon to perform both roles. However, due to the business complexity, the need for quick success, the economic pressures, etc., I don't personally subscribe to the ‘jack of all trades’ model.

Certainly being knowledgeable in both areas makes sense, but realistically I think it is more prudent to focus on the task at hand and collaborate together.  What is your opinion of a business analyst fulfilling both roles?  Do you see fulfilling both roles as a value-add or as a potential pitfall in resourcing?

photo by Martin Pettitt (via Flickr)

---

Steve Bebout is a consultant with over 15 years of experience in information technology in the areas of application development, business requirements, data analysis, and project management.  He has experience in the Communications Media and Entertainment, Financial Services, Life Sciences, and Insurance vertical markets; spending the majority of his efforts on customer data integration initiatives. 

Ready, Shoot, Aim: Gaining Control of Your Data

By Carol Newcomb, Senior Consultant

You’re already familiar with the common symptoms: rapid heart rate, shallow breathing, sweaty palms and jumpy behavior.  When you are asked to identify the strategy for information management in your organization, your mind draws a blank.  “So, I’m not the CIO.  Go ask him!”  When asked about the most reliable source for master data on customers or contracts or sales force, you mumble, “Try the ERP system.  That’s where I found it last time.”  Or if an outside contractor were to ask about your 5-year plan for information management and BI strategy, you shrug, puzzled.  “What good is a 5-year plan when I don’t even have a 1-year plan?  Leave me alone.”  Treading water is the mode of survival.

The single most common problem organizations face these days is too much data.  It comes from all directions for all sorts of purposes.  It comes from dozens of applications designed to fulfill specific functions.  It has grown over the years until reluctantly, one of the organization’s leaders says “Enough already!”   Data is now costing more to manage than it is contributing to informed decisions.  Data is not an asset, it’s a liability!  How did this happen?  It’s like a teenager’s fantasy: wanting and having, wanting and having, bright shiny objects, more and more, until the sobering realization sinks in that the dream is no longer just a dream—it’s a full-fledged nightmare! 

Information management is all about control.  Stop.  Step back.  Get some perspective.  Assess the true situation. Itemize what’s good and what’s subpar.  Think about what the organization needs to achieve.  Think about how the data supports those objectives, not how the organization manages despite its data.  Data management is a deliberate, stepwise set of practices designed to ensure that value can be extracted from the data, and that the overhead associated with poor quality, inconsistent definitions, unaligned source systems and discontinuous data management practices are orchestrated to work as a whole.  The objective is to deliver information value.

So how do you go about changing from ‘Ready, Shoot, Aim’ to ‘Ready, Aim Shoot’?  First, get ready.  Admit that survival is not a strategy.  Survival is survival, and it is getting more difficult to maintain your organization’s survival, much less its competitive edge.  Next, invest the time and resources in drawing that big ugly spaghetti diagram, an inventory of ALL the source applications, software systems, ETL points, staging systems, landing points and delivery channels.  Then, take a true inventory of the end-users.  This is critical, because this is where data begins to result in business value.  Take time to really research who does what with certain pieces of data.  Do they further augment it with external data?  Do they merge it with other internal or external data?  Do they modify it to match other data sources?  How much time do they spend cleaning, standardizing or massaging data?  Start to build your ROI equation.  Data Sources X Time X People = Business Information Cost.  How much is this really costing?  Where is the value?

As you learn more about how the business uses data, start to lay out a business value matrix (the other side of the ROI equation).  This will help prioritize your data management roadmap.  Estimate the amount of effort required to integrate each source against the perceived business value, and chart a business value/implementation effort matrix.  Consider drafting more than one, as this reflects perceptions more than actual fixed units.  Share this information with end users to validate it and socialize a plan.  Then start to lay out a tactical roadmap.  Aim!

Now you’re getting somewhere!  Having faced the ugly reality (Ready) and incorporated real-life facts from business end-users (Aim), you can start to craft your strategy to streamline and rationalize the multiple data lifecycles supported by your organization.   Shoot!  Prioritize the data sources and systems to begin with, and estimate the expected value.  Launch your governance, metadata, quality and delivery resources, and engage your business users each step of the way.  Deliver value and repeat.  Evaluate the process, refine, and keep going.  It’s a deliberate, engaged, transparent and proactive approach, and it’s the only way you will ever conquer those adolescent nightmares!

photo by Erik Charlton (via Flickr)

---

Carol Newcomb is a Senior Consultant with Baseline Consulting. She specializes in developing BI and data governance programs to drive competitive advantage and fact-based decision making. Carol has consulted for a variety of health care organizations, including Rush Health Associates, Kaiser Permanente, OSF Healthcare, the Blue Cross Blue Shield Association and more. While working at the Joint Commission and Northwestern Memorial Hospital, she designed and conducted scientific research projects and contributed to statistical analyses.

Facilitating BI Requirements Workshops

By Fernando Martinez-Campos

 
photo by faster panda kill kill

In this post we will explore ideas for facilitating BI requirements workshops with a group of users. The main goal of requirements discovery workshops is to identify initial BI requirements with key business stakeholders. These sessions start with open ended questions which evolve into detailed requirements. As a facilitator your responsibility is to keep the process on track so business value is derived from the discussions.

The earliest preparatory steps require that you identify the audience participants, create an agenda that will spark interest and schedule the meetings. You will also need to appoint a scribe, who will record the proceedings and capture the output (the facilitator can rarely do both jobs well). I find it useful to also have an initial set of prepared examples that show the progression of an idea into actual requirements. By showing these examples early during the first meeting, you will show stakeholders what the desired outcome of requirements gathering looks like.

Some common steps  in a BI requirements discovery session are:

• Brainstorming ideas – This is the open ended part of the discussion
• Categorizing ideas into business function – This step organizes ideas into groups
• Associating business functions - The groups are related together
• Defining business questions – Initial business questions are chained with follow on questions
• Refining detail requirements - This step translates the questions into detailed requirements
• Prioritizing requirements – Ranks the requirements in order of importance

Let’s use these steps with an example of how these facilitated meetings were conducted at our electronics manufacturer client. The main objective was improving the repair process using BI analytics. The initial session had about eight stakeholders in attendance.

Several categories were developed that had business requirements:  products returned, centers where repairs took place, tests performed, and repair actions. We developed the categories into associated business functions: for example, the Test category had related tests to test results which were associated to the Repair category with repair actions. We continued chaining more questions if the repair action yielded defect trends. By looking at how these business processes were linked, we could track the progress of the workflows in the repair process.

We published the requirements of these workflow activities along with the required data that was needed. On the next session we reviewed, adjusted and agreed on the requirements. Then it was time to prioritize which requirements needed to be implemented and created a roadmap of BI projects.

The BI requirements workshop reaped the following benefits:

• Established solid alignment between the business stakeholders and BI developers
• Documented requirements of the repair process and its analytics
• Reached early stakeholder consensus of the requirements
• Provided visibility on the agreed priorities to set the right expectations
• Provided a forum to communicate feedback and potential risks

As the BI stakeholders gained confidence in the combined effort, follow on sessions became easier. In fact, follow on BI requirements sessions  managed themselves!

---

Fernando Martinez-Campos is a senior consultant with Baseline Consulting and expert in data architecture, data interchange standards, legacy coexistence strategies, and reference architectures templates for infrastructure, applications and databases.

Defining Data Requirements

By Fernando Martinez Campos, Senior Consultant

photo by clayirving

In my last blog post I described a way to define BI metrics through business user interview techniques. Now it’s   time to start investigating what data is needed to answer the business questions. This post discusses data requirements, a subset of business requirements gathering.

A fundamental step in defining data requirements is to build a logical data model (LDM) which reflects the natural way data relates to the business. Aside from interviewing users and building an LDM, another input involves analyzing the sources of this data: operational applications and departmental databases.

Data requirements should be a precursor to data source analysis and profiling. A mistake many analysts make is to assume that the source is good enough to run BI Analytics. Once they load the source, much to their chagrin they find “data surprises” that will make the analysis unreliable. So it is extremely wise to being data source analysis by interviewing the SMEs and ask these fundamental questions:

• Does the data contain duplicates?
• Is there occasional missing data in some of the fields?
• Is there a better source for this data?
• Is the data content recorded accurately and reflect the business event?
• Are the business rules defined when adding or changing the data?
• Is there a data owner responsible for fixing it?

I am always surprised how much users know about errors in their data. They are invaluable in pinpointing where the errors are in the sources. Your initial efforts in the data quality investigation will uncover these “data hot spots” from them. When you start profiling the data to obtain more accurate results on exactly where all the problems exist, you’ll have a great headstart With the data profiling results you will be prepared to proactively handle any unexpected problems with the data before you load the data.

Besides creating the LDM, you will also need to create a Business Requirements Document (BRD) that will have a data requirements section. These are the activities needed to build this section:

• Define the data with a precise meaning and content, in other words, the metadata
• Determine how often the data needs to be loaded
• Determine the cutoff time for the data
• Analyze audit and compliance considerations
• Define the performance requirements and response times in retrieving the data
• Determine if the data has special security and privacy needs
• Define the length of history needed for the data

Creating a BRD streamlines the design phase with these benefits. You can uncover early security, audit and performance considerations that will need to be done in the physical implementation. And data profiling helps you proactively minimize any data quality problems during the load process. Finally, creating an LDMprovides the foundation for the physical data model (PDM) which becomes the de-facto data structure for the tables on your data warehouse.

---

Fernando Martinez-Campos is a senior consultant with Baseline Consulting and expert in data architecture, data interchange standards, legacy coexistence strategies, and reference architectures templates for infrastructure, applications and databases.

BI Requirements: Defining Business Metrics

By Fernando Martinez Campos, Senior Consultant

photo by Aussiegall

When you are embarking on any analysis project, a good investigative technique is to use a variety of structured questions. When interviewing business users, you want to uncover not only how they use information, but what specific information they need, and what they will do with it.

Let’s use this approach with an example: we are going to measure an electronics retailer’s Repair Center activities . These are some of the questions I asked to analyze how the repair process is tracked:

• Trends - Are the defects after repair Increasing or decreasing? For example, is a certain defect trend getting worse or better? 

• Associate - How do you associate defect trends to other trends? Are the defects related to certain manufacturing plant trends? Or are the trends related to specific repair centers?

• Exceptions – What are the exception trends? What is the defect threshold number for a batch of products? What do they do after this threshold is reached?

• Chain - Once you have the results, what is the next business question? If the errors can be traced to a repair center, the next question may be: can we pinpoint the employees that make the most errors, do they need better training? Or is there a flaw in the repair process? The chain of questions and results will give you insights into the business process.

• Other Data - What additional data will you need to improve the process? This involves getting additional sources to enhance the results. If errors can be traced to a supplier, will the manufacturing Lot Number help in pinpointing a batch of defective materials?

As you can see, as the interview progresses, there are more and more business questions being uncovered. You will need to determine how long to pursue follow-on questions. For example, once you have determined that the Michigan Manufacturing Plant has the most defects, is it because they source materials from a specific vendor?  You may follow vendor data until you decide that the scope has expanded beyond your initial analysis goals.  That will indicate that is time to conclude that line of questioning.

When the user gives you a measure, it must be quantifiable and defined in a precise way. The specific measure should move towards achieving an organizational metric and have an actionable target goal. The objective can have lower and upper limits so you can spot variances. As these quantitative measures are analyzed for their directionality (getting better or worse), they should lead to actionable decisions.

Once measures are implemented, you must look at them over time so the business process can be improved. After changes are applied to a process, did the measure results in the direction you expected? Or where other variables causing the problem?

What benefits were realized by using the measures approach? In the case of the Electronics Manufacturer, defining these measures provided standard and concrete ways to track the business. The measures were objective and had universal agreement by all users. They now had a common mechanism to understand what was happening in the business.

Once you are finished defining the key metrics, you are now ready to investigate where you will get the data for them. That will be the  subject of my next post.

---

Fernando Martinez-Campos is a senior consultant with Baseline Consulting and expert in data architecture, data interchange standards, legacy coexistence strategies, and reference architectures templates for infrastructure, applications and databases.

New Business Requirements for BI: Part 2

By Fernando Martinez-Campos, Senior Consultant

photo by D'Arcy Norman

In my last post I introduced the concept of top-down requirements gathering. In this post I'll discuss our work with a client where we put it into action.

Our client was an electronics home entertainment manufacturer that partnered with distributors to sell their products through both the Internet and brick and mortar stores. Increasing their sales and market share was a top priority. But they had a problem: too many products were returned for repair multiple times. This company established the reduction of product returns as a core corporate improvement metric.  

Since Product Quality was now a top priority, BI efforts were enlisted to fulfill this goal. I was involved with a team that analyzed the business process and identified analytic needs that could pinpoint where the quality problems occurred: where they manufacturing process defects, material problems, or labor errors?

We identified each phase of the product life cycle: Sourcing, Purchasing, Manufacturing, Distribution, Sales, and Returns. From each of these phases, we analyzed the related data subject areas in detail, looking for some insight as to where defects were surfacing. Since the Returns area was of prime importance, there was a lot of focus on these types of questions:

• What was being returned (product models)?
• Where was it getting inspected and fixed (repair centers)?
• When was it returned and how long it took to fix (time to repair)?
• Who repaired the item (technical personnel, also what repair station)?
• Why did this problem occur (conclusions that can be reached)?

These were the classical Five W’s that can be used in the analysis process. You can use these questions as a starting point of any BI requirements gathering. It addresses BI Analysis from different perspectives:

• The Business Area being analyzed.
• Inputs and outputs of the process flow.
• Time measurements of the steps in the process.
• People and equipment involved in the process.

These different perspectives ensure that the business problem is addressed in a more complete fashion. From analyzing time, process, people and material measurements, the users will be able to better pinpoint the areas where defects are occurring. A flow oriented model is easy to understand since it follows a product through its lifecycle. It also depicts clear handoff points between manufacturing areas, with inputs, durations and outputs for each step.

Taking the top-down approach and subdividing a business processes into phases is one of the classic approaches of BI requirements gathering, but there are many more techniques that we will explore in subsequent posts!

---

Fernando Martinez-Campos is a senior consultant with Baseline Consulting and expert in data architecture, data interchange standards, legacy coexistence strategies, and reference architectures templates for infrastructure, applications and databases.

New Business Requirements for BI: Part 1

By Fernando Martinez-Campos, Senior Consultant

 Business intelligence requirements gathering has long been an established process in the BI development lifecycle. However the process is changing. In our client work we’ve seen many approaches to business requirements definition. In my next three blog posts I will discuss one of these clients, and present a top-down case study of defining requirements, starting with the business needs for the Enterprise. Then we will explore other different perspectives of BI requirements gathering.

I have analyzed business requirements in many industries and found it difficult to devise a single, standard recipe of questions that could be applied universally across client situations. The best examples of successful requirements gathering tend to be with companies that have easily understood business processes that can be measured, tracked, and improved using BI. Using the example in these blog posts you can apply some general principles to your specific requirements analysis needs.

Before we start, let me explain the the so-called “top-down” approach to business requirements gathering. Top-down requirements analysis starts by looking at the overall business model. Then we proceed to break down the business model into flows, phases within the flow, and opportunities where BI will help improve the business. Top-down analysis has these benefits:

• It aligns top business priorities with BI projects (and vice versa).
• Executive management gets involved in solving business problems with analytics.
• It provides a high level roadmap of business initiatives and BI projects.

Top-down means considering a general business problem at the highest level of the enterprise, the “top”, and subdivide the analysis into more detail. This process ensures that the highest business priorities are addressed first. Then subsequent efforts refine those priorities into implementable projects. Top-down works best when there is a high-profile business initiative and a sense of urgency with executive management. This provides the impetus to fund projects that analyze these problems and implement BI solutions.

The top-down approach is not the only way of gathering requirements —we’ll discuss others in future blog posts.   

---

Fernando Martinez-Campos is a senior consultant with Baseline Consulting and expert in data architecture, data interchange standards, legacy coexistence strategies, and reference architectures templates for infrastructure, applications and databases.

IT and Business Alignment Begins with Listening

By Robert Stone, Managing Consultant

A lot has been written about the topic of IT –business alignment. We see it in action at our clients all the time. Baseline even offers a course on the topic.  I’ve made certain observations about it in my client work over the years that I’d like to share in this blog post.

We find that business intelligence projects are often the optimum way for companies to achieve tighter IT-business alignment. That’s because IT - business alignment will succeed only if you’re solving a business problem.  IT should not show up at a meeting with business users and recite a laundry list of everything they can do.  They should also avoid discussions of technology or existing reports. Instead, they should ask the business what their problems are.  Stakeholders actually enjoy describing what is preventing them from achieving their strategic goals or, at an individual level, what is preventing them from being more productive in their daily work.  IT should listen to the concerns of the business stakeholders and then determine how they can help in an effective manner.   Successful projects will become more frequent because IT already knows the business problems in detail before the project ever begins.

photo by Orange_Beard

Alignment is really all about building a relationship of trust.  If you constantly help business find reasonable and effective solutions then they will trust you.  Trust is also doing what you say—much easier with a set of articulated business requirements in place—and this requires good data management and business intelligence capabilities.

Alignment is not about pitching the business on a new project, the latest BI tool, or the latest methodology. It’s about establishing rules of engagement that can only be followed after earning the stakeholders’ trust.

---

Robert Stone has been with Baseline Consulting over 9 years and is a Managing Consultant responsible for leading and managing large and small projects.  He has over 25 years of IT experience with a diverse knowledge and skill base, and he's focused his skills on using technology to empower business users in many industries.