Skip to main content

The Uncertainties of Integration Projects

Integration is burdened by a lot of misconceptions. The uncertainties of an integration project can be deep enough to evoke hundreds of questions, specific to a company’s back-end systems. This article will focus on five common thoughts where we have seen Integration sales reps dance around one or more questions, possibly because of either shortcomings in products or a lack of knowledge on how Integration really is implemented.

  1. Building Integrations isn’t really easy, right?
  2. How much will I need to spend on professional services, and what particular expertise will that entail?
  3. What is the true time to develop integrations?
  4. What are the real costs/options of the software?
  5. With all of the Standards out there, isn’t Integration pretty straightforward?

Mid-sized organizations may undertake either internal or external Integrations, and projects can cross over data formats and system boundaries. One good example is integrating order data from an on-line store (typically in XML or an intermediary DB back-end) to an ERP system. It’s what many think of as a singular or monolithic integration: it connects two points, crossing data formats and system boundaries.

However, that’s only part of the picture. You may also want to move the information into a CRM application as a subsequent transaction. This can be thought of as a complex (or multi-step) Integration. Some other examples of Integrations involve legacy data movement, EDI, and XML Interestingly, we are seeing an increase in spreadsheet-to-application integration, as spreadsheet formats emerge as a lower-end data-exchange standard du-jour and, as such, represent a tempting staging area for incorporating into other applications.

Why integration matters: islands need to communicate within a company.

Most mid-sized companies have IT departments that are stretched very thin, for any of several reasons:

  • Limited staff and resources;
  • Lack of knowledge and difficulty in finding impartial advice;
  • The cost of solutions;
  • Lack of time to devote to implementation and maintenance;
  • Short-range management perspectives;
  • A lack of understanding of the benefits that IT can provide, and how to measure those benefits;
  • Lack of formal planning or control procedures.

Without these limitations, many if not all the questions would be irrelevant. But they do exist, and lead to inevitable questions.

 

uncertainties1.png

Q: Building integration isn’t really easy, right?

A: This is the ugly truth about integration projects. Typically, they’re tough going. There are tools that can help, but you still need to be prepared to get in there and roll up your sleeves.

There are several considerations, not the least of which are the data formats to be used (How well do you understand the data formats and processes?); the processes to define; communications methods; if you are doing an external Integration, how cooperative is your partner (well-defined specs)? What information have they provided? And, what skill sets are available in-house to achieve this understanding?

Integration does not need to be difficult if customers have an understanding of the following “whats” or variables:

  • Ability to work with data definitions, create definitions that can be re-used;
  • Easy-to-use mapping tool (graphic, drag-and-drop, connect source and target info. Avoid writing code);
  • Business process management, something that is often overlooked. We find that companies are conscientious about the data, but often forget about the processes, and how they can improve them or accomplish more with what they have.
  • Flexible way to use communications adapters. Without them, a company’s infrastructure can really be over-burdened.

So, the key to making the “how” easier is understanding what the tools can do for you. There is a direct link between the capabilities of the tools and the ease of building the integration.

Q: How much and what kind of professional services will I really need?

A: It depends on a few key factors. The first, most logically, is the size of the integration project; then, the capabilities of the tools used; and especially the in-house skill sets.

For large integration projects, “point solutions,” especially where manual programming is involved, can run from 4x to 10x the cost of the software. The sophistication or complexity of the tool, versus in-house skill sets, tends to define the need for consulting. The in-house capabilities need to be aligned with the capabilities of the tool. This may not be an obvious point, but it’s important to keep in mind. You don’t give an 8-cylinder roadster to a new driver, nor send a jet pilot to operate a back-hoe; match the tool to the skills and experience of the user.

Users can, in fact, leverage a pilot project as a mentoring stage, something we see pretty routinely. The real key, where I have seen the best ROI, is to define a small pilot-project and engage a professional services group to mentor your team. This allows a skill-set transfer, won’t consume a large amount of resources, and produces a usable Integration, rather than a throw-away.

In other words, the pilot project doesn’t go away after implementation, it actually goes into production. The concept has been proven, and the results are immediate. Because of the capabilities of contemporary Integration tools, these pilot projects only last a few weeks. They can be an effective way to measure the rate of knowledge transfer and still end up with a usable result.

Q: What is the true time to develop integrations?

A: Several factors tie in to the first question (Integrations aren’t really easy!). I’ve worked with companies where the IT folks staff the new systems inside and out. They were able to grasp the tools and run full-speed. We also have the converse situation where a smaller company has a business analyst who is savvy and is thrown into the mix as the Integration person. They have “some” knowledge of the processes, a passing familiarity with the data formats and a limited background with the notions of mapping and data conversion.

Then, we have “the rest of us.” So, this is too broad a question to answer generically. There are usually metrics available, for example, to map an EDI 4010 Purchase Order into a back-end database. Even though there are tons of DBs out there, you are still doing similar things (header/detail records etc). Professional services teams usually have a good handle on these types of metrics.

The answer lies within the capabilities of the tool and how easy it is to understand and start leveraging it. A good example is a tool that can take a flat-file document and allow you to easily “discover” the structure of the document. That would save you from having to build the data definition by hand.  Web services have been designed from the ground up to aid this process by providing a schematic of the services and request/response data formats within a descriptor document called a WSDL.  This self-describing nature is also inherent in XML documents, but requires a dictionary to leverage the business relationships of the data.

Understanding your business goes a long way towards developing integration. That is, besides understanding the company’s own business processes, it helps to also have an understanding of the data formats. Awareness, from the general to the specific

There are no real absolute answers, just a range of times that have been observed from projects. However your first pilot project should definitely be scoped to only take a few weeks to a month. You want to attain a completion, without burdening the user with a large knowledge-transfer upfront.

Integration tools can help accelerate the process, and a few key principles come into play:

  • Easy-to-use visual tools reduce learning curve
  • Reusable objects improve development efficiency
  • Integration tools can reduce complexity and therefore reduce dependency on consultants

Testing the Integration is a key area that gets lost in the time estimates, so always keep that in mind.

Q: What are the real costs/options of the software?

A:  By their very nature, most sales people want the prospect to buy the whole enchilada. They want the prospect to think of integration architecture and enterprise-wide solutions together. The fact of the matter is that there are packages designed for the company to buy just what they need at the present moment, and allow them to grow into the full solution later.

Oftentimes, a sales rep. has the option to sell you less than the full-blown system, but may not let you know that until you ask. Depending on your corporate setting, you may be addressing a mandate such as an EDI standard from a large trading partner. In that case, you are looking at a tactical solution with some interest in moving into Integration at a later point.

Given the complexity of enterprise-systems today, it can also be overwhelming to think, from the start, about all the touch-points where Integration would be a benefit. Being able to buy a “slice” of a full Integration solution is a valuable way to solve your immediate need, and introduce you to the technology at a hopefully lower price-point.

Finally, be cautious of hidden costs, such as training time/ramp up.

Q: With all of the Standards out there, isn’t Integration pretty straightforward?

A: Yes, one interesting thing about standards is that there are a lot of them (see graphic, for standards relevant to Integration); and they all want you to do things their way. That’s why they call them “standards.” But, there are no “formal” integration standards, just technology standards. There are ways of thinking about Integrations, templates or patterns to follow, but no hard-and-fast rules on how to do Integration. It’s not just about connecting the dots.

Quite often, standards are simply guidelines Understanding your data and processes is a fundamental requirement when thinking about Integration.

Let’s talk about one of the real reasons why Integration exists; it’s what I call the “Standards Oxymoron”… the notion of standards regarding data. There are standards for what the data looks like, how it is transmitted, etc. There is one great thing about these standards; they are so popular that you have a lot to choose from. Every flavor of data has someone attaching a standard to it, from XML (RosettaNet, large-customer proprietary formats) to the EDI (X12 and EDIFACT). That is why we are talking about Integration; if we just had one common layout for File and Database, we wouldn’t have a lot of these issues.

 

uncertainties2.png

 
Another aspect is the agility to deal with new data formats, as they emerge. Spreadsheet formatting is at the forefront of this movement. Whoever would have predicted: spreadsheets as a common data foundation for Integration?

Being equipped with these questions will better prepare a company to deal with the inevitable promises and uncertainties of an integration initiative. Considering a few of points will be especially helpful.

  • Start with a pilot project and mentoring
  • Think strategically: where is your business going?
  • Ask yourself, “Do I need the whole picture or just the key pieces first?”
  • Your existing team, with their existing skills, can be successful.

Vendors ranging from software companies to integrators to some-of-each will do their best to sell their approach. Knowing the questions will better equip you to sift through the answers.


Mark Denchy is Director of Product Management at EXTOL International. With more than 20 years’ experience in the software field, he has a wide-ranging background in application development and platform integration. He works with several clients on leveraging new technologies that enable integration.

This article originally appeared in DM Review

ITIL for BAs. Part IV; The Service Catalog

The Service Catalog is one of the primary artifacts of an ITIL-based organization and its orientation toward the business as an IT Service Provider.  The Service Catalog is the source of information on all IT Services in operation or being prepared for operation and identifies status, interfaces, dependencies, delivery levels, and other attributes.  And in the spirit of encapsulation, the Service Catalog is written in the language of IT’s customers, free of the details about how the service is delivered from an infrastructure point of view

Think of the Service Catalog as the IT “menu” and a Service Level Agreement as a particular customer’s order from that menu.  (Service Level Agreements and the Service Level Management process will be the topics of a future article.)

For the BA, the Service Catalog is in one sense an inventory of IT building blocks that contribute to the creation of business solutions.  The BA then is interested in, and dependent upon, the catalog in terms of its completeness, accuracy, and its suitability as the basis for specifying the requirements of an IT Service to meet business requirements.

itil1.png

Because of its importance in expressing IT’s purpose and value, the Service Catalog must be maintained through the Service Catalog Management process.  In looking at the key triggers, inputs, activities, and outputs of Service Catalog Management, it is clear that the BA has much to contribute toward the content and maintenance of a high-quality catalog:

Service Catalog Management Activities

  • Agreeing on and documenting the definition of an IT Service – that is “What do we mean by the term ‘service’?”  Services must defined to a level of granularity and detail to support their use in business cases in terms of functionality, risks, costs, and other attributes of interest to the customer, so the definitions decided by IT need to be useful to the BA.
  • Interfacing with the business to identify and document customers’ dependencies on the IT Services and those customers’ needs relative to business continuity (i.e., recoverability).  When IT is faced with the need to prioritize (and when it is not?!), decisions need to be based on their relative impact on the quality and availability of IT Services – guidance about which is received from those knowledgeable of the business cases for having those Services in operation.
  • Interfacing with the business to ensure that the information in the catalog is aligned to the business.  The Service Catalog needs to be accessible by various business stakeholders, and just as with business solutions in general, the BA would represent to IT any business requirements regarding the operation of the catalog.

Key inputs to the Service Catalog Management process are clearly in the BA’s domain and include:

  • Information on business strategy, financial plans, and current and future requirements
  • Business Impact Analysis – information on the risk, impact, and priority of each service

Much of the BA’s involvement in this process is indirect, addressed as part of the normal set of activities throughout the business solution life cycle.  In fact, many IT organizations have survived without any Service Catalog, so its role and value can be elusive – so let’s conclude with a few relevant points:

  • The goal of ITIL is to encapsulate all of IT in terms of IT Services, expressed in the language of IT’s customers – in other words, ITIL helps an IT organization separate the “what we do” from the “how we do it” – lifting from the Customers’ shoulders the significant burden of having to understand the IT infrastructure and its commensurate complexities, costs and risks.
  • The IT organization’s mission should be to deliver IT Services with a “service culture”: every IT contributor should be able to see his or her contribution to service quality and availability rather than working solely within his or her particular silo.
  • BAs themselves are also very driven to make a distinction between the what (business requirements) and the how (the solution to satisfy those requirements).

Back to the “menu” analogy we started with – imagine a restaurant where you can order a meal only after you understand the details about how the kitchen operates, what ingredients it has in stock, which kitchen tools are available, etc.

What about your IT organization?  What is the maturity of the IT Service Catalog?  Have you participated in the design and operation of such a catalog?

Federal Government

The country is buzzing with excitement over the new administration.  Promises of a “change in government” have created optimism about government not seen since Reagan. 

How will this new administration be effective?  How can this new administration properly administer the agencies of federal government and affect change?

My current projects are examples of the complexity of working with federal government:

  • Data consolidation for nine federal agencies 
  • Multiple systems across agencies and within some agencies
  • Standardization of 40 agencies on one system and set of business processes 

What are your challenges in helping government be more efficient?

We, as business analysts, have the opportunity to help our country by making government more efficient and by getting more accurate information to decision-makers.  We can help government standardize and modernize so the type of data available to CEOs of corporations is available to congress and the president. 

In summary I leave a challenge to you and to myself:

How will we, as business analysts, help the new administration get the information it needs to be effective and help streamline and modernize government operations?

Post your comments here or email me at [email protected].  Or you can visit me at my LinkedIn page at http://www.linkedin.com/in/jmalkin

Embrace Change, But Make Sure It’s for the Better

“Embrace change” is a useless platitude mouthed by managers or motivational speakers who have not thought through its full implications – or they are masochists who enjoy suffering. Changes that bring new opportunities or propel us forward are easy to embrace. But many changes look quite negative and are tough – if not impossible – to welcome. This list might include loss of a relationship, a loved one, health, job, money, and such.

We usually don’t choose the difficulties or negative changes that spring upon us. But we always choose how we respond.

Above or Below the Line: It’s a Critical Choice

For the past few years, I have been using a simple concept to discuss our choices in dealing with difficult problems. Surveys and feedback from my workshop or retreat participants continually point to the few minutes we spend on this basic model as the most powerful part of our time together. It may be basic and seem obvious, but many of us seem to need constant reminders and help because it is so easy to sink “below the line.”change1.png

There are grey areas slightly above and slightly below the line. This is “survivor” mode. When this is our response to a difficult change or problem, we’re sitting on the fence to see what might happen, or we are waiting for someone else to do something. There are times when waiting in survivor mode and not acting immediately is quite wise – as long as we are above the line.

Examples might be when we need more information and have to do some research, or to see whether a change is going to become a trend, or which way the new boss, government, or customer is going to go. The top of the graph – well above the line – is proactive “navigator” mode.

When we’re here, we’re trying to capitalize on the problem or change. Or, if capitalize is too extreme a word, we may be at least trying to figure out how we can make the best of – or work around – a bad situation. In this mind set we’re like the seasoned ship captain of old, he knew he could not control the wind and currents, but he could adjust the sails and steer the ship to make the best use of the winds and currents to move toward his destination.

Below the line is the dangerous territory of reactive “victim” mode. When we’re in this head space, we’re bitter, helpless, and feeling like others are out to get us or deliberately want to do it to us. In this “blame storming” mode we might point fingers at politicians, bosses or senior management, other departments, customers, competitors, and the like. Decades of research by University of Pennsylvania Psychology professor, Martin Seligman, shows that explaining events in our lives in this state of “learned helplessness” leads to lower performance, poorer health, and higher rates of depression.

What Pulls People Down

The feeling of helplessness shared by many people in their organization is a major contributor to low organizational morale. Here are some of the common causes:

Forces beyond our control. Mergers, acquisitions, changing governments, organizational power games, bureaucratic decisions, new technologies, competition, boom/bust cycles, security threats, dumb rules and forms, globalization, and such leave many people feeling like dispensable pawns.

Nobody ever tells us anything. In a world overflowing with information, most organizations have little open and transparent communication. So “us against them” rumors attempt to explain what’s going on and why.

We’re swamped. Many people’s e-mail inbox, voice mails, phone calls, and meeting schedules are overwhelming, as work encroaches on personal time and stress levels keep rising. This leaves many people feeling helpless and frustrated.

It’s popular. Cynics, doomsayers, and conspiracy theorists often get more attention – especially if they use disparaging humor, sneering personal putdowns, and mocking sarcasm.

Fear is more believable. In a Canadian poll probing irrational anxieties, pollster Allan Gregg asked, “If someone told you something was safe and someone else told you it was unsafe, which one would you believe?” He found that an astounding “68 percent would accept the message of doom and gloom” without questioning who was telling them and what they were talking about.

Society encourages victim thinking. People who make bad decisions to hold paper cups of scalding coffee between their legs while driving, drive drunk or carelessly, take drugs, or smoke cigarettes for 40 years are encouraged to “make somebody pay” for what they have done to themselves. Watch daytime TV talk shows for plenty of examples. Seeing positive possibilities in a calamity or making the best of a bad situation is much tougher than joining the crowd that’s given up and wants to play the poor-little-victim against some other group or external force.

It comes naturally.  Most people can quickly identify what’s wrong. It’s less instinctive to focus on what’s right and build upon that. It takes much more courage to correct a problem than to point and complain about the problem while waiting for somebody else to fix it.

Shift Your Perspective: Life isn’t Fair

Lots of unfair and unjust stuff happens to undeserving people. Whatever hits the fan is usually not evenly distributed in most workplaces. But it’s our choice whether to stand in it or not. Taking a navigator response to difficult issues means facing problems head-on by focusing on what’s within our direct control or what we can try to influence. We then need to figure out how to let go of, or at least not ‘awfulize’ and give more power to problems or issues that can’t be controlled or changed.

It’s recognizing that the best thing to do when it’s raining, is to…let it rain. Here are some ways to be less of a victim and more of a navigator through difficult career or workplace changes: Be aware of your mental state and limit downtime – the ever popular and rapidly growing “Pity City” – or even its suburb, “Frown Town,” can be a therapeutic place to visit occasionally. We all need to grieve or vent our frustration when faced with major losses or setbacks. But don’t join any co-workers wanting to take up residence in Pity City (one workshop participant claimed her department head was mayor!).

That leads to deepening cynicism, despair, and inaction. Pay attention to your own moods and watch for defeatist language like “they will never listen,” “what’s the point,” “we’ve tried that before,” or “why bother.” Keep the problem in perspective – don’t get so drawn into the issue that it’s all you can see. Step back and look at the bigger picture. What’s going right? What’s working in your favor? How could this change lead to something better? What are the possibilities?

Talk through the situation with a colleague, mentor, coach, or spouse. Describing and discussing the circumstances will force you to re-focus on what’s happening – as long as you don’t commiserate with people who love to find conspiracies everywhere and be a victim. Dispute your doomsday scenarios. When your head is buzzing with dread and worry, examine your beliefs about this issue or change.

Challenge your thinking through weighing objective evidence against your fearful outcome. List more desirable alternatives or what you would prefer to happen. “Decatastrophize” your long-term fears by recalling all the times things have worked out successfully in the past. Examine and question the usefulness of dwelling on your feared belief or concern. Harness the power of imagery and counterbalance fears of what all could go wrong by ensuring you have a clear picture of what outcome you want from this situation. What would a successful result look like? What would you be doing with the key players involved? How would you be feeling? What mind set have you adapted to rise above the difficulties and problems? What actions might this lead you toward? Step back to step ahead. The busier and more frantic the pace of work becomes, the more critical it is for you to carve out personal reflection and renewal time.

Avoid the busyness trap of adding ever higher quantities of work time to compensate for the diminishing quality of that time, as you slowly burn yourself out. Set limits on your workday or workweek. Pursue hobbies, personal interests, or family activities. Get away on periodic mini and longer vacations. Meditate or learn other stress reduction techniques. Monitor and carefully manage your creative energy.

Change your self-talk – catch yourself saying things like, “I am too old to change,” “That’s just the way I am,” “He makes me so mad,” and replace them with more accurate phrases like, “I choose not to change,” “I am comfortable with the way I am,” or “I make myself mad when he says/does…”, or make action plans to change. Help pull others up In dealing with changes and problems in your workplace; you’re either part of the problem or part of the solution. Here are a few ways to help your colleagues or your team navigate more effectively through your endless challenges and issues: Speak up! Challenge, involve, or problem solve with those people who insist on picturing the worst outcomes and living in Pity City. By letting those comments go (or even worse,  joining in), you’re allowing the naysayers and cynics to set your team’s emotional tone and spread helplessness.

Refocus their thinking. Focus discussions on solutions and the future, not on the past or why nothing will work. You might need to point out that raising complaints without possible solutions can be unproductive and even harmful to the team. If team members or co-workers insist on remaining a victim, you might encourage or even help them to find another job.

Celebrate progress. Look for small wins and steps in the right direction that you and the team can build upon. You might periodically list what’s going well, or list your team’s accomplishments.

Find healthy ways to ventilate frustrations.  One team initiated a fine system whenever a member made a hopeless victim statement. It was a useful way to raise money for the United Way and called anyone to account for comments that brought the team down and poisoned their spirit. However, they soon found a need to vent frustration with the actions of another group or the challenging problems they were facing. So they added rituals like someone raising their hand at a meeting and asking for “permission to visit Pity City” for a limited time or scheduling a “grump dump” as part of their meeting agenda. It’s important to do a periodic “reality check” on how we deal with adversity and change.

One reality we can choose is to transform tough changes into positive results. Another possible reality is to wait for somebody else to take action or tell us how we should feel. Or our reality can be anger, bitterness, and helplessness. To choose our response is to choose our reality.


Jim Clemmer’s practical leadership books, keynote presentations, workshops, and team retreats have helped hundreds of thousands of people worldwide improve personal, team, and organizational leadership. Visit his web site, http://jimclemmer.com/, for a huge selection of free practical resources including nearly 300 articles, dozens of video clips, team assessments, leadership newsletter, Improvement Points service, and popular leadership blog. Jim’s five international bestselling books include The VIP Strategy, Firing on All Cylinders, Pathways to Performance, Growing the Distance, and The Leader’s Digest. His latest book is Moose on the Table: A Novel Approach to Communications @ Work.

Facilitating Discovery Meetings; Be Prepared

When I was a Boy Scout we had a simple motto; “be prepared”. The same motto applies to facilitating discovery sessions with your stakeholders. In general, people are tired of attending meetings and discovery sessions. In the business world, business analysts, project managers, senior managers and all other stakeholders are busy people who deserve to have their time leveraged wisely. Here are some of the techniques you can use to get participation, gain consensus and leverage your stakeholders in discovery sessions and meetings.

  • Get your introductions established with key takeaways from the participants. This helps the facilitator align the session objectives with stakeholders expectations. 
  • Establish the “rules of engagement” and “who they are as a team”. The rules of engagement provide a context for the session structure and acceptable behaviours. The team question helps establish how the participants see themselves. 
  • Be clear on the “business problems” being addressed and the “solution context”. Clear business problem definition should be created in partnership with the sponsors and senior stakeholders prior to the session. The solution context provides a framework for the participants to frame their thinking in addressing issues. It does not mean the facilitator is providing solutions. 
  • Use a variety of people and group dynamic tools and techniques. For example,
    Brainstorming in a non-judgemental way to capture the thinking of individuals and teams. Make sure that you follow brainstorming rules.
    Buzz Groups to buzz on an assigned topic for 10 to 20 minutes that have been established by the facilitator.
    Team Pods to group people into working units at common tables facing one-another so they get engaged.
    Play games. Do not be afraid to play games. Games provide a means of getting participation engaged and the information you need to have a successful session. This is where your creativity comes in. Have fun!
    66 Technique. Six people discuss a topic for six minutes. Give the group structure by assigning a chair, a scribe and an auditor to provide feedback on the groups’ efforts.
    POPs. Get the POPs (points of pain) and align them with the organizations maturity.
    Nominal Group Technique. Use the Nominal Group Technique to have team members identify their best solution to business problems through a process of rating and elimination.
    Cost, Ease, Benefit. Use Cost, Ease, Benefit analysis to have participants clearly define and understand the impact of their recommendations.
    SWOT. Get the SWOT, that is strengths, weaknesses, opportunities and threats, and identify those things external and internal that the team needs to focus on.
    Fish Bone. Throw them a Fish Bone (a diagram) to stimulate ideas and thinking as to the root cause of a business problem.
    Debate Teams. Create Debate Teams and have the groups discuss all sides of an issue. Ensure that there is structure and everything is timed and scribed.
    Smart Objectives. Have the groups make objectives SMART through ensuring they are specific, measurable, attainable, relevant and timely.
    Implementation Plan. Build an implementation plan with assigned tasks, core responsibilities and timelines. Ensure there is a follow up mechanism.
  • At the end of the session there are a few other things the facilitator should do. Consider these items:
    Summarize and Review all that has been said to ensure clarity and alignment with the sessions key objectives.
    FUDs. Get the FUDs (fears, uncertainties and doubts). Have the stakeholders write these down, in confidence, and hand them in at the end of the session. There is nothing better than knowing the stakeholders concerns.
    Communication. Establish a follow up plan. Communication is key to understanding what the participants expect. Be clear on expectations and follow through.
    Positives and Deltas. Request the positives and the deltas regarding the session. Review these as they will provide the facilitator insight into areas for improvement.
    Scale it 1 to 5 and ask how the stakeholders feel about the decisions, recommendations and the overall initiative. You might find that they see things as just another shade of what they did last year. Be prepared to leverage the information gathered.
    Get yourself evaluated. You need to grow.

There are lots of approaches, tools and techniques that you can apply to creating discovery sessions and meetings that provide value to the participants and stakeholders.

Your job? Be prepared!


Richard Lannon is an international business and technology industry veteran turned corporate speaker, facilitator, trainer and advisor. He specializes in aligning the enterprise and technical skills to common business objectives. Richard helps organizations and professionals identify what’s important, establish direction and build skills that positively impact their bottom line. He provides the blueprint for your organization to be SET (Structured, Engaged and Trained). His clients call him the SETability Expert. He can be reached at [email protected] or 403-630-2808.