But what does “leading” really mean? The first time I heard the phrase my immediate reaction was: Huh? That sounds terrible. Are they not going to strive to be the best airline? Aren’t they trying to be #1 like most would assume is the goal of a merger? But by what measure? Size? Revenue? Fleet age? Service and satisfaction? Destinations served? Complaints? Lost bags?  Cost management? 

For an industry with dozens of closely watched measures of performance, creating a public marketing message to be “leading” is vague and pointless to me. It’s also a bit risky. After all, vague or non-existent goals will always make you successful, but maybe not in the way you intended. It is a safe way to go, though, if you are not sure what you’re doing or how things might go. Maybe the new United will be able to say by the end of next year, “We’re leading with the worst ontime performance of any airline!”. That’s nice.

We’ve all heard the phrase “for good measure.”   Hey, throw in some extra salt for good measure! Maybe you do it just in case what you’re cooking tastes terrible. It seems rather arbitrary. Why not taste it first? So, a more thoughtful approach to planning and success may be in order. I have worked with plenty of clients who do not understand how to make a good measure. Their five year plans are a wealth of vague, uncertain and impossible to measure goals, usually in an attempt to placate many differing views.

Think about this as you are setting goals for the new year for yourself or your organization.  Are the measures meaningful? Can they really be measured? Is the necessary data collected? How will you know you have achieved the goal? Is it actually a good measure people will recognize as success?

After all, if you are ”leading” the airline industry that still has a terrible overall reputation for service, you haven’t really set a good measure or accomplished much.

• I prepared a project proposal that was not accepted by the prospective client. Unexpectedly, another nearly identical request came along resulting in very little work to respond quickly. The first round was not wasted effort!
• I’ve beenworking with a client to resolve performance issues with their BI platform. The visibility of the project has imposed a lot of pressure on the team to make signficant improvements. Progress has been frustratingly slow. Yet, I am learning an incredible amount about the more detailed workings of this platform and how similar configuration improvements can be made elsewhere to benefit other clients.
• A coworker and I have had tense disagreement about the strategy for a proposed solution. We usually get on quite well. But the frustration, arguments, and counter arguments helped lead to a breakthrough “aha” moment as to how to proceed.

What are some examples you’ve experienced? Whenever something bad happens, look a little deeper… wait a little bit… look at another angle. There will very likely be something good to come of it.

Many of the clients we work with are asking the same kinds of questions proposed in the article. These questions are a logical extension of the research results. They want better insight into student behavior and achievement and what administrators can do to increase student success:

• Are students who place in a developmental Math or English course taking that course? Do they succeed in that course and then succeed in the college level course?
• Are students ignoring the developmental course requirement and do they succeed at any different rate than those who pass placement tests? (The article suggests students are quite good at self-selecting into the college level course and ignoring the test results!)
• What are the characteristics of students who do not succeed at developmental or college level courses?
• Are there specific courses or pathways that are more successful than others based on historical activity?

Of course, all of this really gets to the efficacy of the entire placement and developmental education system. Some states, with the help of research foundations, are attempting to address significant problems in misaligned curriculum between the developmental course and the college level course that should follow. Similarly, they are also applying new research in learning to redesign curriculum for greater real world application and effectiveness. The Developmental Education Initiative is one example.

Our job as BI consultants is to effectively understand the business questions and help institutions with the collection of useful data that can be presented in a way that informs the change process. We have several client engagements currently underway that are doing just that. I’ll be able to see for myself from exposure to specific institutions what the state of developmental education success is for their students.

First, let’s clear up one of the common misunderstandings that I have seen on various comment threads on LinkedIn and elsewhere. Despite the fact that John Speer, current CEO of Datatel, will lead the new combined company, this is not Datatel acquiring SunGard HE. Hellman & Friedman, a venture capital firm that already owns Datatel, is buying SunGard HE with plans to meld the two companies into one. As such, I would tend to consider the transaction a merger of equals. Hellman & Friedman clearly have a greater understanding of the higher ed. marketplace through the eyes of Datatel management – having owned them for the past several years – while SunGard HE brings the greater client base and broader product and service portfolio. In the end, I believe that we’ll see a blend of products and services from the two companies that it truly will be a fusion of the best talent from each that rises to the top.

But it is a long way from here to there. The first 18 months will be the consolidation phase. There is much duplication between the two companies that will have to be dealt with. While the two companies do essentially the exact same thing, I don’t think we’ll see much in the way of product or service consolidation from the outset. Early on we will see layoffs in areas such as accounting, human resources, corporate IT, sales, and marketing. I suspect that software and services will largely be untouched. If layoffs are to be had in these areas it will be more about productivity and utilization then it will be about product consolidation.

Now, let’s speculate about product and service direction.

If you are running Banner or Colleague, don’t worry; neither of these systems is going away any time soon. In fact, I would expect the combined company to double-down and provide even greater focus to each of the platforms. Datatel has been increasingly looking to base its solutions on Microsoft technologies, while Banner is essentially married to the Oracle platform. Look for the company to further position Colleague around the Microsoft database and application eco-system as the technology will largely be the differentiator between the two ERPs.

New ERP sales in higher education are drying up. They have been for the past several years, with near 100% saturation of the target market. As a result, the company will need to eat into the client bases of the other remaining ERP companies. Look for Banner to be positioned against Oracle PeopleSoft customers, while Colleague will be aimed aggressively at the Jenzabar client base.

So what about PowerCampus? SunGard HE acquired this Microsoft based solution from ABT several years ago. After some initial investment in the student system early on, this application never seemed to gain enough traction in the industry. In the medium term, I would expect some kind of “upgrade” package presented to PowerCampus clients, designed to get them to move to Colleague.

From an overall product perspective, my guess is that new functionality will increasingly come from partner companies and software development efforts will largely be directed toward integration technologies. It’s likely the two companies will pool resources together to build common APIs and data transport technologies to help partner and 3rd party companies tie into each of the ERPs without having to do twice the work.

Business Intelligence has been a big focus for both companies in the last few years. The myriad of tool options between the two is dizzying. Expect for further consolidation around the Business Objects platform for Colleague clients and Cognos for Banner. The real action is in the data models, however. Each has a fairly well formed set of operational data models. I would not expect too much in the way of new models, as it is likely that the two will want to standardize on a single data warehousing model that works for either system.

So, what do you think? Poke some holes in my analysis above. Speculate some yourself in the comments. I’d love to hear more from some customers themselves.

When a Canadian friend of mine who happens to work for SAP Business Objects, forwarded this link to me that showcases their BI platform, I was ingtrigued. It takes full advantage of their analytics and data exploration technologies using hockey statistics. I mostly deal with higher education related data like student enrollment, retention, financial aid, and human resources. This was different and fun!

I took a look at how Washington stacked up against their second round rival Tampa Bay. Hmm…. Not such a good picture. Tampa Bay had higher average Goals For and lower Goals Against. Their offense and defense looked better by the numbers. I looked at the goalie save percentages. I compared some key individual players from each team. Everyone thought the Caps would keep winning and go to the finals. After exploring some of the data and visualizations, I wasn’t so sure of a spot in the finals. And, in fact, it didn’t happen. Sadly, the numbers seemed to support that outcome.  Certainly there is more to hockey than just numbers. Passion for play, pure skill, wanting to win, and luck sometimes create amazing upsets. That’s what happened in last year’s post-season. (And seemingly in every year’s March Madness for all of you college basketball fans!)

Of course statistics don’t always tell the whole story. Lots of other variables can come into play. And often good analysis includes domain knowledge with the human element to enhance any interpretation. But I can’t help thinking that those stats didn’t lie, and the results certainly bear that out. Now with Vancouver in the Cup finals and Tampa Bay winning tonight to force a game 6, It’s time to go back and do a bit more research and exploration!

Take a look at the site. Play around. Even if you don’t know much about hockey, it’s a good way to become familiar with some of the great analysis and visualization tools available in Business Objects. Maybe you can improve your chances of winning the office Stanley Cup pool!

What a great quote from Dr. Brene Brown at the University of Houston. You can see her TED Talk here for more about how she elevates the use of data to make change at her institution.

(Via Brand Autopsy)

And then it happened. We all were working together, as client and consultant team, to address the punch-list of items that needed to be fixed before “turning on the switch” and going live to the broader set of business users. I heard it. The language from this person changed. The ownership suddenly appeared. ”I have to research this data anomaly”  and “We have to finish the user cheat sheets and handbook”  and “I have to test this to be sure the security setup is working correctly.” 

To be honest, I am not entirely sure what triggered the change. Maybe it was the deadline of this new reporting environment being put out for all to use and either accept or reject.  And, naturally, someone deeply involved in that kind of project and commitment ultimately wants their positive imprint on a successful outcome. I know I sure did.  I suppose it is like the bird leaving the nest, or the child going off to school on their own for the first time, or maybe a teenager taking the car out for a drive by themselves after getting their full license.  Taking ownership or responsibility is perhaps a natural part of the human process of becoming more independent.

I am gratified to see this change andexperience the benefits of the client ownership in their evolving BI environment. Although  the details of this true story may seem to be unique and even readily identified by those involved, this happens in every engagement. It is not unusual, nor a cause for concern–unless, of course, the ownership never materializes .

Keys to a Successful BI Implementation with Howard CC

The S’s in Success

The Meaning of Success and Failure

Many people assume that success and failure are mirror images of each other; to succeed is simply not to fail; to fail is simply not to succeed. But if the goals, the hoped for results, of a project are less than fully realized the mere absence of obvious failure need not be the same thing as success. Nowhere is this phenomenon more common than in implementing major business application software (e.g., SIS, ERP, BI, CRM).

Failure seems like a simple idea, but when we try to examine it in detail it turns out to be more complex than one might expect. As I have discussed throughout the series, the potential for failure includes quite a few entirely different things.  In fact it’s hard to imagine anything worth doing at all that couldn’t fail in more ways than it could succeed.

Typical Success Rates:

Reported rates on BI project success vary from survey to survey, but tend to be consistent. The 2009 BI Scorecard survey [1] of 324 BI professionals found that 29% of BI deployments were slightly successful; 47% were moderately successful and only 21% of the respondents rated their deployments very successful. The rates were largely unchanged from the last survey in 2007.

In short, the majority of BI implementations fall short of being very successful and usage continues to be hindered by a number of factors.

So what do we mean when we describe a BI project as a success or failure? What are the symptoms of dissatisfaction with BI initiatives? Let’s look at the evidence. This is my own list of common symptoms of failure, but it is consistent with my meta-analysis of BI case studies and other published lists.

First, it is apparent that users and builders view both the symptoms and the causes of BI failure somewhat differently.

Symptoms of Failure:

• Users still have poor access to data and information.
• Solution outputs don’t match decision-makers needs.
• Missing reports, queries analytics.
• Business decision-making has not improved.
• It doesn’t do it my way.
• Too complex or hard to use.
• There are data integrity and/or data accuracy problems.
• There were/are data conversion problems.
• ROI remains a challenge.
• It just doesn’t work! or similar statements of abject despair.

One striking thing about all these symptoms is that they all appear after the fact. That is, there are no early warnings on this list, nothing that suggests were going to have a problem if we don’t do something now.

When asked for the causes of these symptoms, users and builders typically list the following (the wording varies from survey to survey).

Causes of Failure

Users:

• The wrong platform was selected.
• The BI solution was designed or configured incorrectly.
• Inexperienced/inept builders.
• Builders didn’t take the time to understand my needs.
• BI solution was underestimated or oversold.

Builders:

• Users kept adding and changing requirements. This is the universal first response
• Lack of user skill. Many flavors (some unprintable), among them:
  • They have nobody who understands anything in that department
  • They refuse to change how they work.
  • We showed them over and over again and they just didn’t get it.

Both:


• They lied.
• Lack of management commitment/support. This is the single most commonly cited general cause of failure, but often it is offered without an explanation of exactly what management should have done differently.

Some rather surprising things emerge when we compare the list of commonly reported symptoms of failure to the list of commonly reported causes of failure. First, almost any commonly reported symptom could be the effect of almost any commonly reported cause. Actually, the relationship between reported symptom and reported cause is even more nebulous than that (if possible). Second, there is nothing in either list that suggests how to avoid these results. The closest we usually come to are statements like:

1. management should have been more involved (without explaining what management should have done that they didn’t;  or
2. requirements should have been better expressed (without explaining which particular requirements were misstated or omitted).

Of the causes of failure (risk factors), the last one “Lack of management commitment/support” is the most critical.  To be successful, any institution must decide why a BI solution should be implemented and what critical business goals the solution will address. Hence, identifying business goals, determining the strategic business issues, ROI and strategic requirement identification are essential elements of the BI planning process for success. Alignment of the BI strategy with the institution’s business strategy must be enabled by senior executive support. If an institution tries to install a BI solution without establishing a clear vision, every effort can turn into a disaster .Remember that failing to address it can lead to every one of the effects (symptoms) of failure.

As I discussed in part 2 of this series, it is one thing for senior executives to establish a clear vision; it is quite another thing to ensure that everyone else shares and buys into it. Senior executives’ do not implement BI systems, but strategic business issues and a strategic vision need to be spelled out in unambiguous terms that everyone on the BI project team shares long before the first requirements are defined and any technical implementation decision is made. These are the keys to success.

Planning for Success

We are only planning for success when the vision and requirements we are working to are the same as those by which our efforts will be judged.

A relatively small number of symptoms or effects of failure, around ten of them, are responsible for all BI implementation failures. Each of these can follow from a somewhat longer but still quite short list of risks (or potential causes of failure).

Managing each of these risks must be a plainly visible requirement, because systems are not turned on until the perceived requirements have been met and they are invariably turned on as soon as the perceived requirements appear to have been satisfied.

Among the requirements that must be visible to everyone involved in the new BI initiative, is the obligation to conform to the institution’s strategic goals and objectives. The translation of these goals and objectives into concrete business processes and tactics is critical if project success is to mean the same thing as day to day operational success after the solution is implemented.

With BI projects, many of the biggest failures have resulted from attempts to utilize a traditional application or software development plan (methodology) that produces the wrong work products, and as a result, the wrong solution.

[1]  BI Scorecard, Survey InformationWeek, December 21, 2009.

For some additional insights on BI success, I refer the reader to the following Campus Technology article. BI Project Success.

]]> http://www.asranalytics.com/leading-for-success-with-your-business-intelligence-initiative-part-7/feed/ 0 http://www.asranalytics.com/leading-for-success-with-your-business-intelligence-initiative-part-7/ http://feedproxy.google.com/~r/AsrAnalytics/~3/JpI5At7mjNE/ http://www.asranalytics.com/leading-for-success-with-your-business-intelligence-initiative-part-6/#comments Wed, 27 Oct 2010 17:06:57 +0000 James Riha http://www.asranalytics.com/?p=467 In my previous post Leading for Success with your Business Intelligence Initiative: Part 5, I discussed some additional C’s to success.  Today, I would like to discuss the E in success.

The E’s in Success

The first “E” is Education

While training in technical skills and project management is a good investment, there are a myriad of soft skills that can help your BI team take more responsibility for success. Group problem solving, communication and conflict management, facilitation, change management and understanding how human systems typically function are critical skills that can improve success.  There are many ways available to receive training in these areas.

In addition to formal skills training, the BI team needs to educate the other members of the BI team on the epistemology of the stakeholders that they represent.  Understanding the epistemology of the stakeholders and the institution is the keystone to creating a true learning organization, establishing a culture of evidence, building the right solutions and achieving pervasive BI success.  I will discuss my thoughts on the epistemology for BI in a future post.

The second “E” is for Executing the plan

In my 30 years of experience, I have found most large, innovative, or complex projects are all seeking a state of “entropy” – a way to go bad.  I have always assumed a project was going bad until proven otherwise – assume proven guilty until proven innocent.

Many IT people attempt to run BI projects but lack the knowledge or resources to select the correct project management methodology and then find themselves’ being run by the project.  The key axiom to successful project management is:  Plan the work, then work the plan. I will discuss the appropriate project management methodology for BI in a future post.  What I will state now is that the traditional project management methodologies and techniques used for traditional IT application development and software development will not produce the appropriate work products required for a successful BI project.

My 5 rules for successfully executing a BI project plan

Rule 1: Make sure you are doing the ”right” project.

You need to identify what initial BI project is right for the intended stakeholder and the institution, and then make sure everyone minds their own business.

A.    Checklist to selecting the initial right project

1. Is there a clear purpose for the project and does it make sense?
2. Is there a clear business case (positive value proposition)?
3. Do you have the right sponsorship?

Rule 2: Prepare a reasonable plan

A.    Checklist for a reasonable plan

1. Have you selected an appropriate BI project management methodology?
2. Are the resources, schedule and requirements in balance?
3. Have you defined a strategy for keeping stakeholders and BI team members involved in constantly reviewing the plan?

Projects take resources, and we all know that you may not always get what you want, but if you try hard and communicate well you may get what you need! We also know that we may not have all components of the plan in balance.  That’s normal, the difference between the plan you want and the plan you have is called “risk”.  Managing this risk needs to be a part of the plan.

Rule 3: Build the right team with clear ownership of tasks

A.    Checklist for the team

1. Are there clear task assignments and ways and means of doing the work?
2. Is there a strategy for providing timely feedback?  Performance does matter?
3. Have you taken the steps to avoiding the work breakdown structure?
   • Overlapping responsibilities
   • Ambiguous assignments
   • Vague accountability
   • Unreasonable expectations

These are all major demotivators for stakeholders and project team members

Rule 4: Track status and give it visibility that is has both depth and width

I have previously talked about the need to have a high communication plan for the BI initiative, but it is also essential to regularly communicate the status of individual BI projects.

A.    Checklist for project tracking

1. Pay attention to the results and make changes as necessary
2. Strategy for continually tracking and reporting on progress status
3. Strategy must include
   • Progress reports for BI team
   • Progress reports for the intended users
   • Progress reports for the executive sponsors

Rule 5: Expectation Management

Managing expectations is a critical key to your projects success, your own personal success and saving your sanity. Let’s face it; everyone wants their BI systems and projects delivered yesterday, even if they don’t have a clue about the amount of work involved in delivering a quality solution.  I’ll discuss this topic in more detail in a future post. What you need to understand for now is that perception is reality and all BI projects are really just a reality that someone in the institution would like to see. Your job is to manage your sphere of influence regarding the project; i.e., the piece of the pie that you can actually directly impact via your work responsibilities. Remember, no one is immune from the need to manage expectations, it is only your place on the project food chain that defines at what level and how formally you need to manage these expectations.

A.    Checklist for expectation management

1. Have you identified all the key stakeholders?
2. Have you identified the real needs and wants of the stakeholders, the organization, the BI team, etc?
3. Can you answer the following question? When will we know when we are done?   If you can’t answer this question, then you don’t have a manageable project yet and you will not be able to manage expectations.

In my final installment of this series, I will discuss the “S” factors in Success.

]]> http://www.asranalytics.com/leading-for-success-with-your-business-intelligence-initiative-part-6/feed/ 0 http://www.asranalytics.com/leading-for-success-with-your-business-intelligence-initiative-part-6/