Archive for December, 2008

BPM Excuse Busters – Episode 2: “We tried Business Process Re-engineering already and failed.”

Wednesday, December 10th, 2008

Anyone who was around the business world in the 1990s couldn’t escape the two big topics of the decade – the Y2K bug and Business Process Reengineering (BPR). The fear of the unknown drove huge investments to address Y2K and the result was…well, nothing really came of it. On the other side of the coin, the promise of efficiency and cost reduction drove many companies to undertake huge BPR efforts. Michael Hammer and James Champy’s 1993 book “Reengineering the Corporation: A Manifesto for Business Revolution” was the BPR Bible. It was a NYT Best Seller for 41 weeks. Numerous firms embraced BPR and responded to Hammer’s motto: “Don’t Automate, Obliterate!”

Unfortunately, many BPR projects suffered failures, costing companies millions without showing any measurable ROI. As a result, many business and IT people remain skeptical a decade later of the promises of Business Process Management. To many, it appears that BPM is just another version of the failed ideas of the past. They fear spending tons of money with no return. They fear losing their jobs as a result. While understandable, these fears are unfounded for a number of reasons. Consider the following:

  • BPR failures were not due to inherent problems with BPR. BPR projects failed for any number of reasons. Many of these are the same reasons any large IT/Business program fails:
    • Misalignment of business and IT
    • Poor Change Management
    • Lack of Executive sponsorship, business ownership or accountability
    • Inability to overcome internal resistance
    • Over-sold expectations and under-sold investment requirements
    • Poor definition and management of scope
    • Lack of appropriate technical skills
    • Budgetary cut backs
    • Analysis paralysis

The list is endless. But the fact remains that many BPR projects avoided these obstacles and were completed successfully, providing significant positive impact on the organizations they changed. As with any IT project, BPM projects are susceptible to these same risk factors. But when properly executed, they can overcome these risks and show value; there is nothing inherently broken about BPM.

  • BPM is not BPR. Sure, they sound similar, but the main philosophy with BPR is to radically change the way a company does business. While one can take this approach with BPM, it is not the only way. In fact, in my last blog post, I explored how BPM can show benefit without any process change at all. So don’t let BPR horror stories or even an organizational aversion to change taint the possibilities of BPM benefitting your organization.
  • BPM embraces a more deliberate, iterative approach. Remember the BPR mantra: “Don’t Automate, Obliterate!” BPR eschewed small process change in favor of major change. The philosophy was that BPR was revolutionary, not evolutionary. While this approach can yield much greater impact, it also comes with greater risk. BPM embraces an iterative, evolutionary approach that requires less investment before seeing positive ROI.
  • Today’s technology landscape is different. In the mid-1990s, the technology focus was on client/server technologies. The web was just beginning to take root and grow. Windows95 was the first usable GUI on a mainstream operating system (bringing it almost on par with Macintosh System 7 from 1991). Graphical modeling environments were rare. Most major processing still required Mainframe computing power.

Contrast this with the technological capabilities of today. Internet technology is ubiquitous. Web Services standards, Enterprise Application Integration and Services Oriented Architectures enable the exchange of data and choreography of processes like never before. Numerous platforms exist to enable Business Intelligence, Data Analysis, Business Activity Monitoring, etc. Visual process modeling tools are commonplace. Graphical dashboards allow complicated data to be communicated and understood quickly and easily. The bottom line is that today’s technology enables so much more than that of 10 years ago. BPM efforts can capitalize upon these technology advancements.

  • BPM places more importance on the “B”. While the “B” in BPR stands for Business, many BPR projects were IT-driven projects. As a result, many projects were not aligned well enough with the business to succeed. When done right, BPM projects are business-focused and business-driven.
  • BPM Suites. When BPR at its peak, there were few tools available to assist with the process. In fact, I was personally involved deeply with the development of an early BPR tool (called Apache – later renamed Process Vision) at Electronic Data Systems. Ironically, although I witnessed significant successes brought about by use of Apache, I also recognize that the effort was conducted out of EDS’ R&D organization. Thus, it had a bit of that “IT-driven” nature mentioned in the previous bullet. We were one of a very small set of sophisticated BPR tools available at the time; business units seeking to take on a BPR project did not have very many places to turn nor much of a “services economy” to support those efforts.

Today, there are many viable Business Process Management Suites (BPMS) that can be leveraged. These products robust provide out-of-the-box functionality to jump start your BPM efforts. But they offer much more than that. Most BPMS’s provide the capability for: business process modeling/analysis, process simulation/optimization, monitoring/reporting/notification, business rule integration, lifecycle management and much more. In addition to the solid offerings from pure-play BPM vendors such as Global 360 (an Avalon Partner), Lombardi and Pegasystems, enterprise application vendors like IBM and Oracle have BPM solutions as part of their product suites.

Conclusion: Busted!

While there is a similarity between the excitement around BPR in the ‘90s and that of BPM today, there are also significant and structural differences. Thus, there is no need to fear BPM because of failed past attempts to address BPR. To do so would ignore all of the potential benefits that are absolutely critical to remaining competitive in today’s rapidly changing business world.

What are some of the excuses that you hear against pursuing BPM – justified or not? Let me know what barriers you encounter and I’ll try to address them in future posts.

Posted in BPM | No Comments »

e-Learning Part 2: Getting on the Right Track with Upfront Needs Analysis

Tuesday, December 9th, 2008

In my last post, I discussed the steps an organization should take to begin identifying the type of e-Learning program they need. Once you have determined the type of training that is right for your organization, you can begin to analyze your content further to understand the level of repurposing necessary for an effective e-Learning initiative. This analysis is conducted to determine compatibility of existing content and legacy courseware with e-Learning delivery methods (not all content lends itself well to e-Learning delivery!) In this step of your path to e-Learning, an instructional designer analyzes the organization’s course content to determine the appropriate delivery methods to:

  • Optimize learning transfer and retention
  • Reduce training costs
  • Expand learner population through increased accessibility, and
  • Create on-demand training programs.

Why all the analysis?

Although many organizations cite an interest in offering e-Learning and believe it can add value to their overall training strategy, many fail in the execution stages due to inadequate front-end analysis. Optimal e-Learning design takes the following inputs into consideration:

  • Gaps between current training and performance requirements
  • Level of learning desired to ensure learner retention
  • Best delivery types for each course
  • Costs related to design, development, and deployment
  • Time-to-market requirement
  • Technological capabilities and resources available to support the delivery

An organization that fully understands each of these inputs as it pertains to their particular needs can more accurately identify their e-Learning environment and resource needs and thus establish a path to develop an e-Learning program that provides a substantial return on investment. Once this analysis is completed, the organization is prepared for the subsequent development phases.

What is learner retention about and how does it impact delivery decisions?

Understanding the importance of learner retention is a critical consideration in designing effective e-Learning. Learner retention is the extent to which learners remember what they have learned and can transfer those skills to their work or life. The design of e-Learning is driven by the learning or performance objectives. Utilizing Bloom’s taxonomy, if the learner is required to perform higher levels of cognition such as application, analysis, synthesis, or evaluation then the instructional content should require the learner to perform these tasks within the content. The following table demonstrates the relationship between cognition levels and delivery types:

Level of Cognition

Description

Delivery Types Examples

Knowledge

Observation and recall of information

Instructor-Led Lecture

Instructor Assist

Computer Text/Graphics

Job Aids/Training Guides

Discussion Boards

Recordings

Online Discussion Groups

e-Book

Broadcast

Comprehension

Interpret facts, compare, contrast, grasp meaning

Lecture/WBT content followed by instructor/ learner Discussion

Online discussion board postings

Case study

“Drag and drop” exercises

Essay questions

Online discussion groups

Application

Use methods, concepts, theories in new situations; solve problems using required skills or knowledge

Case Studies

Lab exercises

Simulation

On-the-job observation

Video observation in which correct application must be identified

Essay questions

Analysis

Recognize patterns; Identify components

Lab exercises

Simulation

Essay questions

Case Studies

Synthesis

Use old ideas and create new ones; Generalize from given facts; Predict, draw conclusions

Essay Questions

Research Problem/Report

Simulation

E-Class projects

Evaluation

Debate a concept; Judge and/or predict a problem

Essay Questions

Research Problem/Report

E-Class projects

Debates through discussion boards

 

Mapping delivery methods to learning retention given the realities of your organization

When transitioning content, I always recommend that you find an experienced instructional designer to analyze legacy content prior to transitioning it to e-Learning. An instructional designer will conduct a high-level analysis of the organization’s legacy learning objectives (for each course) and supporting materials. They will then determine which courses lend themselves to an e-Learning environment. Once this is determined, the instructional designer will analyze the courses identified for e-Learning at a higher level of granularity, assessing each learning objective to determine the appropriate delivery method to maximize learner retention.

The cost of development for each delivery method varies greatly due to the amount of time and expertise it takes to develop.High e-Learning development costs are associated with flash video and simulations to enable learners to use higher cognitive levels including application, analysis, synthesis, and evaluation.If these types of delivery methods/costs are outside the institution’s business model, then there are delivery methods that can be utilized to encourage higher levels of cognition, but keep development costs down. It should be noted that although initial costs are high, the costs of delivering self-paced training over an extended period of time are low by only requiring the organization to revise the training modules when necessary.

Once the organization has identified which courses can be transitioned to e-Learning and what delivery types to use to maximize learner retention, the organization can begin conducting due-diligence on learning platforms to deliver content.

Please stay tuned for my next post: Getting the Biggest Bang for my Buck: Things to Consider when Choosing a Learning Platform.

Posted in e-Learning | No Comments »

How to run a development project when you don’t know much about IT: 3 Truths for Success

Monday, December 8th, 2008

As a creative director (who also happens to oversee the Web development projects) for a direct-marketing company, I am well aware that I am always the most technically challenged person on the project team. High school math and a journalism degree only get you so far. But, like the ancient Egyptians who relied upon big logs, sand, and clever ramps to create pyramids the size of office buildings, I’ve learned to make the most of my skill set. I’m also in charge, so people pretend not to notice my shortcomings.

Surprisingly, after nearly a decade in this role, I’ve acquired some expertise on how business people and developers can work together better—drawing on each other’s strengths and understanding each other’s weaknesses. Following are three truths I live by:

1. Developers will complicate everything if you let them.

Techies can be too smart for their own good. Yeah, that’s you: Always a dozen lines of code away from pure genius. There’s an algorithm to solve every problem. Rien n’est impossible! But why buy a turbo-charged power blower to clean up leaves in your front yard when a $20 rake will do? Sometimes old-school simple is better. We non-technical types are here to keep the brainiacs grounded in reality. So trust your instincts and don’t be afraid to assert some common sense over a runaway process—and be particularly wary when anyone insists on talking over your head. If all else fails, remind everyone who is footing the bill.

2. IT people can write beautiful code, but don’t count on them to make things sensible (see 2a) or pretty (see 2b).

2a. Developers will relish tackling any problem you put in front of them—the trickier the better—and will likely do so in a literal way. The best developers are the ones who care as much about the business requirements and usability ramifications behind what you are asking for as they do about your specific request. Those of us unfamiliar with technology sometimes latch onto ideas that seem cool, or land on technology-related solutions to a problem, without fully thinking through the root issue. Developers often assume that we have fully vetted an idea, when in fact we haven’t. We think we’re brainstorming and, meanwhile, the developer is writing project specs. The lesson here is to remember Truth #1, which ensures that what gets built solves a business problem you actually face (as opposed to solving a business problem that someone else faces, or one that nobody on Earth faces).

2b. Unless a creative type intervenes, the presentation layer will be ugly. People like me, who live and die by our ability to spec a proper typeface, align design elements on a grid, and piece together cute outfits even on our days off, forget that these skills are not universally shared. You’ll be happier with the result if you assign a visual person (e.g. graphic designer) to the project from the very start, which will relieve your technical team from having to think about whether your project is having a good hair day or a bad hair day.

3. Treat your development team like siblings.

We all got labeled as family members: The Smart One; The Wild One; The Whiner. Each of us has a role to play and none is necessarily better than the other. Bridge a partnership with developers who—like your brothers and sisters—you can trust with your humanness. Show them your stupidity and silliness and encourage them to show you theirs. Hold each other accountable for mistakes, but know that mistakes will happen. In the end, it’s the connections between us that give our lives and our IT projects meaning. You just have to believe that the bonds between us are more powerful than the ones that pull us apart.

Posted in From The Outside Looking In | No Comments »

Is Secured Enterprise Search Too Risky? Not if you know your Secured Search Engine and use it! – Part 1

Tuesday, December 2nd, 2008

We were recently engaged in a classic conversation at a research organization that does a lot of top secret work. You may have heard similar conversations where you work. It went something like this:

Person A: “We can’t let our people search repository X because that information is highly secure.”

Person B: “But repository X contains invaluable knowledge and to remain competitive, we need our new workers to find crucial tidbits from that captured knowledge contributed by our retiring work-force. Plus, we can add the security rules to our search engine so everyone only sees what they are supposed to see.”

Person A: “But the risk is too great!”

Person B: “What about the risk of losing work to competitors that share knowledge within their organization?”

Have you had that conversation at your workplace? If so, how did you decide whether to share knowledge and deal with the security risks, or to avoid the overt risks and leave the knowledge in difficult or impossible-to-access systems? Feel free to post your comments.

And why is it that we only worry about security risks sometimes? Isn’t it interesting to contrast the uproar about Google Desktop Search uploading your search index containing all your personal data to their servers with the lack of uproar about the same risks related to letting Gmail host your personal mail? Are we ok if the government or disgruntled Google workers can read our Gmail? Do we really just need to accept that software is inherently insecure, that there is no such thing as privacy anymore, and “get over it”? I really don’t believe so.

I believe most of us only worry about security sometimes because we are wisely extra cautious about new and unproven systems. We need to stand up and fight for security and privacy. We need to learn the security capabilities of our search engine, and use the capabilities offered while demanding the capabilities that are missing. In that context, I like it when clients challenge me on the ability of their search index to be “truly” secure. This gives me the chance to educate them about what security features their search engine does or does not support.

Let me quickly debunk some myths I’ve heard both from clients and vendors:

  • Myth #1: Search engines cannot fully respect our custom security model.

    • Truth: While many search engines are very limited in their support for custom security models, many other search engines are fully programmable and can thus support any security model.
  • Myth #2: Search engine security will always be out-of-date.

    • Truth: For most search engines, the timing of updating search indexes can be as frequent as you choose. When necessary, updates to security credentials can be reflected immediately within search engines.
  • Myth #3: Security is built-in to the search engine, and automatically respected with no extra work required.

    • Truth: As with any technology, the security within your search engine is only as good as the planning and testing you invest to validate the required level of security.

Ok, now that we’re past the myths, and ready to replace paranoia with planning, I’d like to do a high-level review of important questions to ask yourself about your search engine when you’re ready to consider adding secured content.

  1. Does your search engine support your security model?
  2. Will you use Early or Late-binding security?

then a question to ask if your users need to search across multiple secured data sources:

  1. Can your search engine support multiple security models simultaneously?

In my next post I’ll provide some detail behind these three questions and some guidance to help you find the right answer to each.

Posted in Search | No Comments »