In the Field with our Experts

The Change Paradox

By Carol Newcomb, Senior Consultant

Change is hard.  How does your company manage change?  How do you personally respond to change?  Why does it seem like everything changes at the same time, or that it’s never-ending?  How can you possibly do your daily job while incorporating all the NEW ideas and NEW technologies and NEW demands on your time?  When are you supposed to get a chance to actually think about the purpose of changes, and figure out how to put them all together into a manageable pattern?  Sometimes it just seems like all too much!

I recently worked for a few years studying patient safety in hospitals, and collecting a lot of data from across the country on types of errors.  Humans, it turns out, are very adaptable, but also very entrenched in our learned patterns of behavior and physical agility.  By this I mean that things like driving a car, while initially quite challenging (remember how to slip the clutch while starting from a dead stop on a snowy uphill slope?) become simple with repetition.  After a while, you don’t even think about all the little steps involved, and you just quickly let out the clutch, gage the slipperiness of the slope, and adjust the gas.  No problem.  And when some smarty-pants (like your husband) tells you you’re doing it all wrong, the response is undoubtedly scornful.  Such is most people’s response to change.  “I can handle this myself, thank you very much.”  Remember your first response to having to use a mouse or a keyboard?  Several doctors I know were not too tickled.

And yet humans are also very adaptable.   The literature on patient safety, and use of other technologies for that matter, document how once the brain stops consciously THINKING about how to do something, the subconscious brain kicks in and takes over, instinctively executing each step of a process without needing to affirm the need for each particular step.  It becomes part of a repeatable pattern—like lifting a beer mug without spilling a drop—or speaking a different language—that you can do without conscious or deliberate parsing of each micro-step.  With enough time and practice, humans can adapt pretty well.

As consultants, what we work on with clients ALWAYS entails change.   And here lies the paradox.  While most clients look for consultants to make recommendations—to help them  with things they are challenged with, to provide expert advice, to design a new way of managing their business, to recommend new technology, to train staff on new ways of collecting information, etc.—the ability to consume that advice or to incorporate new practices is tempered by the organization’s sensitivity to the impact such changes will have on their environment.

How many times have you heard, “That’ll never work here; our culture just isn’t like that” or “That may be a ‘best practice’ but who has time for all the extra work?”  New ways of doing things may be good ideas, but deliberate attention needs to be spent on incorporating them, digesting them—so to speak—so that they are not only accepted, but willingly practiced and even improved on over time.  The biggest risk, when we leave a consulting engagement, is that the organization will simply ignore or reject our suggestions, and go back to business as usual.

This is the Change Paradox: Change is good, but change is bad. Change is hard when there is too much change at the same time.  Change is necessary, but it can be overwhelming and destabilizing, especially if it compromises the work at hand.   Change can be refreshing if the purpose and the steps are broadly understood and accepted, otherwise it can be a needless waste of energy that ultimately accomplishes nothing.  Change can introduce new ways of thinking about the business and smarter ways to achieve business goals, but if can feel like chaos if not managed in digestible increments.

As you embark on a new project or a new set of practices, take the time to enlist the understanding and acceptance of those who will be most impacted by the proposed changes.  Provide the time, the training, the leadership vision and purpose, and the support resources to ensure that all the ‘newness’ can be incorporated, repeated and rewarded.  Change is simple, but it’s also complex.

Image by Rafa Garcés via Flickr (Creative Commons License)

---

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.

The “And” Syndrome: How to Keep BI Development Proactive

By Mary Anne Hopper, Senior Consultant

Remember way back when your Business Intelligence organization was a small group of one or two people?  And then business found value in what you were producing so your group grew?   And then you created clear roles and responsibilities for the team?  And you started creating project backlogs?  And your group continued to deliver great results for the business?  And your team grew more?  And then things seemed to slow down in your ability to deliver and it was hard to figure out why?

Could it have been that each time you delivered new functionality, someone had to stop what they were doing to support it?   The impact of this can mean missed delivery dates and ticked off end users.

Each time the business needs something they have the ability to talk directly to the person who built the functionality for troubleshooting everything from data loads to data anomalies to report issues.  So, every time functionality is introduced into the environment, somebody is in charge of supporting it in addition to their ongoing project delivery responsibilities.

I call this the “and” syndrome.  Nobody can support “insert system/data/report functionality” and “insert system/data/report functionality” and “insert system/data/report functionality” and “insert system/data/report functionality” [I’ll stop here because you get the idea] without impacting the ability to deliver new functionality.

Here are some tricks and standards I’ve seen in different organizations along with their results.

Across the board reduction in project allocation (eg 10% of developer’s time is dedicated to support issues)	This can wreak havoc with project planning as the project team never knows when that “10%” will occur
The development takes turn with support on-call duties	This causes a lack of continuity with development efforts, especially when developers are moving in and out of support issues
The person with the least development impact supports the issue	This results in prioritization discussion each time there is an issue that needs to be addressed
The person who developed it will support it	This creates the “ands” scenario and does not accommodate staff or role changes as the organization grows

Does any of this sound familiar to your organization? If so, it’s time to step back and review your project plans. One of the biggest mistakes BI teams make is not acknowledging the fact that BI projects will likely have multiple releases.  Each new release will likely be a new project with its own plan.  Moreover IT management should acknowledge that BI needs support resources—including problem resolution experts, training, and documentation specialists—who will support new releases and enhancements to BI applications and the data they use.  Factoring in these issues will allow your group to get back to delivery, and stop supporting all the “ands.”

---

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.

MDM and All That Jazz

By Rob Paller, Consultant

Recently, senior consultant Bob Wall mentioned building the team as one of four proven starting points for getting your MDM program rolling. By now, you have probably identified the C-level executive experiencing the most pain as a result of working with unmanageable data. You have even gone so far as to identify a small project that allows you to demonstrate the value that MDM will provide the company.

However, the success of your MDM pilot project and overall MDM strategy will come down to the team you assemble to support it. Interestingly enough, there are a few parallels that can be drawn from what makes up a good jazz ensemble that can be applied to building your MDM team. Every musician must possess a core set of competencies—just like employees possess in order to do their jobs. However, in order for a jazz musician to excel, he must possess an additional set of skills that is, for the most part, unteachable, but enables him to reach a level where his inspiration and creativity matches his ability to execute. 

• A jazz musician must be a virtuoso of his instrument in order to communicate what he visualizes in his mind instantly through his instrument. An MDM team member must be a subject matter expert with an innate technical understanding of the source system or a similar understanding of the business processes surrounding the subject matter.

• A jazz musician must possess a trained ear that is not only able to identify something being "in tune" or "out of tune," but hear the melodic structures and chord progressions. A soloist must be able to adapt to the piano player making chord substitutions underneath the soloist's performance. Any member of your MDM team needs to be able to find the nuances in the business when it comes to defining the core subject areas of your business. For example, defining what a "student" vs "alumni" vs "donor" means to your university.



• Many jazz musicians are able to recall hundreds of songs at a moment’s notice—not only the melody, but the chords as well. Your MDM team must understand how and be able to explain the countless business processes and policies surrounding your master data.


• A good jazz musician must be able to listen and interact with the group in the present moment and contribute to improving the overall quality of the performance. This is one of the most important skills that an MDM team member needs to possess. The MDM team must be willing to listen to the rest of the business and communicate effectively. There are no ivory towers in MDM or jazz. 


Keep in mind when assembling your MDM team that it must be a balance of members from both the business and IT—much like a jazz ensemble consists of a balance among percussion, brass, and/or woodwind instruments. If you are unable to find a balance, you risk discord in what you produce.


photo by Fillmore Photography via Flickr (Creative Commons License)

---

Rob Paller is an expert at business analytics and database administration. Since joining Baseline, Rob has been responsible for developing a case analysis system to streamline the oversight of food assistance benefits, implementing a common citizen data model, and assisting in the rollout of a new public assistance data model integrating data from over 10 years of legacy with a new benefit eligibility determination system.

Managing the Informal Leader in your Project

By Steven Bebout, Senior Consultant

As a former Officer in the US Army, I know the importance of leading a team, creating esprit de corps, and providing communications (upward and downward).  Whether in a training exercise, in a forward area, or back in garrison, leadership and understanding are vital to achieve success and prevent dissension among the ranks (regardless of the mission).

You may ask, ‘what does this have to do with business intelligence’, I would say a lot.  The project team is composed of many different players: Project Manager, Technical Lead, Lead Architect, Lead Business Analyst, along with many others.  As in the military, these leaders set and manage expectations, create alignment with other leadership within their own company (or for consultants with the client).   Working in a vacuum is not an option.

One player may emerge during your project is the 'informal leader'.  The informal leader holds perceived or real power over rank and file and potentially higher level stakeholders in an organization.  This persuasive and typically respected individual can derail a mission, project or change success criteria. This individual’s agenda and their influence with the rank and file can put a fork in the road to success in a military or a project in corporate America.

How do you prevent the emergence of an informal leader in your BI Project?  You can’t; you can only manage them and bring them on board immediately!  How do you do this? Prior to the project kick-off you are provided a list of interviewees; this list comprises individuals for a multitude of reasons.  The project sponsors and leadership have identified the list; I assure you, the ‘informal leader’ is part of the list.  Interviewees can be:

• Highly Influential
• Visionary
• Mover and Shaker
• Supporter
• Naysayer
• Politically Necessary

Under one of the interviewee types lies your informal leader; typically a naysayer.  Manage their expectations, incorporate them within the decision-making process, and empower them.  Remember to apply the adage of Sun-Tzu’s to "keep your friends close, and your enemies closer."

How have you dealt with informal leaders in your projects?  Are there key triggers to identify this individual?  If so, what are they and have you ever found there to be multiple informal leaders?

photo by The US Army 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.

The Metadata ROI Series: Episode 4: Program Management

By Stephen Putman, Senior Consultant

This posting is the fourth in a series discussing various aspects of the financial justification of a metadata management system implementation that are not obvious in many existing analyses. Today, we will discuss the time and effort saved by Information Technology program management staff in system implementation projects.

In Part 3 of this series, the return on investment in a metadata system was shown in relation to end-user reporting groups in your organization. In the fourth and final installment in this series, we will look at how a metadata system can strengthen the program management of the entire system development process.

A great deal of a project manager’s day is spent assembling various lists of functionality to be released into the production environment, and checking the progress of these pieces to ensure that everything is completed in time for the scheduled release. Much of this work is done manually by checking with the various producers, either in person or by status report. It is, frankly, a complicated juggling act that introduces risk into the release process that does not need to be present.

With a robust metadata system, participants in the development and testing of data solutions have a central repository to place updates on the status of various pieces of the product. Unfortunately, status reporting is something that is often neglected, and therefore such a system could easily fall into disrepair. There is a solution that serves all parties, however - the program management group enforces a policy that no piece of software or reporting moves into another state in the standard development-testing-production progression unless the metadata for that piece is complete. This way, the program management staff has an up-to-date view on the status of the entire feature list, and the development staff has incentive to enter data into the system, which benefits all of them during the process and the end-users when the features are released into production. This ultimately saves the organization money in increased efficiency of the entire staff.

A robust and comprehensive metadata system has many benefits to several areas of your organization, and along with effective measurement can provide a large return on your investment in either a purchased or “home-grown” system. It is the basis for effective software development and support in your organization, and should be seriously considered as a best practice for a successful IT function.

photo by perhapstoopink via Flickr

---

Stephen Putman has over 20 years experience supporting client/server and internet-based operations from small offices to major corporations.  He has extensive experience in a variety of front-end development tools, as well as relational database design and administration, and is extremely effective in project management and leadership roles.

The Project Manager as News Reporter

By Stephen Putman, Senior Consultant

photo by rabbleradio

I recently read a post on the PM Blog relating to Data Integration Management Processes. In the post, the author details the seven steps in the Project Management Book of Knowledge (PMBOK) Guide relating to a Data Integration project for completion of a project. The steps are pretty much what you would expect-- develop a project charter and scope, develop the project plan, implement change control, etc.-- for any project, not just Data Integration. I found one of the steps particularly interesting for what it left out:

4. Direct and Manage Project Execution The Project Manager needs to make sure that everybody is doing what they should be doing...(emphasis mine)

The italicized statement is a huge assumption-- it supposes that the manager and team knows what tasks are required, how they are related, how long they should take, and why they are required. In other words, it supposes that the project manager can answer the famous "six questions" that all reporters ask about a news story. Unfortunately, many times this is a faulty assumption, since project managers do not necessarily have experience in data integration solutions, and may not have access to this expertise.

At Baseline, we answer these questions every day:

• Who - Who should be involved in each step of the implementation process
• What - What should be done to successfully accomplish the project, based on vast experience in developing and implementing industry best practices
• When - What sequence in which the tasks should be performed, and how they are related to each other
• How - The skills required to accomplish the tasks, and the ability to identify these skills in client staff
• Where - Assumed to be the client site (the least important question)
• Why - How detailed tasks relate to a proven project implementation methodology that has been developed by Baseline

The simple act of answering these six questions puts you well on the road to successful project completion. Of course, that?s not all there is to it, but it?s a good start?one that a surprising number of experienced project managers forget!

---

Stephen Putman has over 20 years experience supporting client/server and internet-based operations from small offices to major corporations.  He has extensive experience in a variety of front-end development tools, as well as relational database design and administration, and is extremely effective in project management and leadership roles.