Project X Discussions

Scope Creep and Other Horrors

• What can you do about scope creep?
• What are the causes of scope creep?  
• Is it inevitable?

I think everybody becomes creative as we think about a project.  I was thinking of adding a bathroom at the cottage and before the conversation finished it became adding a whole new wing onto the cottage.  Of course, nothing happened because the project was too big.  What happened to the simple idea?

I think part of the cause is nothing is ever perfect and can always be improved upon.  You know the expression "Anything worth doing is worth doing well."  I think it might be unsaid but that it really means "anything worth doing should be perfect."

I have a relative who spent a long time getting his PhD.  He said he just wanted to do an adequate job.  I think adequate was his definition of perfection.

Another cause of scope creep is people's unwillingness to take the Rapid Results approach.  Get something working and then make it better, faster.  We are all scared that we will not go the next step and thus never finish.

Very few of us can tolerate the creative tension between our vision and reality.  See my blog on that subject,   Creative Tension

I would love to hear from some Project Managers stories about scope management.

 

People Are Motivated By "The Why' not "The How" of Data Governance

If people understand and accept "why", they will figure out how to make it happen.  This idea provides a practical application of the three principle of Motivation 3.0, Autonomy, Mastery, and Purpose.  Do project managers spend any time discussing why?  They usually focus on what needs to be done.  

We spend very little time on the "why" because we assume people see things the way we do.  However most organizations see data governance as simply extra work and "not my job."  Let's go back to first principles and consider why data governance is important for everybody.  

Just read a great blog on data governance and it reminded me of this principle of motivation

the-collaborative-culture-of-data-governance

Here is a quote from the blog.

"A data governance program needs to begin by communicating why data governance is necessary before communicating how it should be done. To paraphrase Friedrich Nietzsche: "An employee who has a why to work for can bear with almost any how."

"In his book "Start with Why: How Great Leaders Inspire Everyone to Take Action," Simon Sinek explained that it is not the products or services that bind a company together or make it strong; it's the culture, the strong sense of beliefs and values that everyone, from the CEO to the receptionist, all share."

So why is Data Governance so important for everybody?  The business intelligence provides information critical to my success in the organization.  Misleading information  leads to wrong decisions.  My success in my job depends on the decisions I make.  In this changing world, data errors can doom an organization to failure in a blink of an eye.  If data does not ring true, ask about the governance process.

Dan Pink wrote an article in the Daily Telegraph about "why" and some important research see Asked yourself why you're in business.

Let's all critically examine the "why" in what we do.

Being Right and Data Quality

Over the past 2 months I have found myself listening or participating in conversations that were driving for an absolute answer. I am by far no mystic guru or physocologist, but it is sad to see the energy we spend endeavoring to be right. Please don't take me wrong, this is not an excuse to be sloppy. But let's take a conversation like data quality. I witnessed a conversation the other day about some data that was of issue. It turns out a data dictionary and an understanding of the EDW was out of date due to some changes in an operating model. After reviewing the impact of this change is it flowed to a downstream system a straightforward way to deal with the issue was presented. This was well received by everyone and the conversation of changing it at source was avoided (as the data was still correct, but just needed to be interpreted differently). Fast forward a month. Some anomalies again started to raise there head. The data still seemed to be off. So some further analysis reconciled the issue, but then the ugly let's change it at source as other downstream consumption may be wrong. So let's not worry about the outcome in reality, let's review our options. 1. Change data at source. Always my preferred method if practical. In this case, the data at source was not an issue. So we could change the transformation rules that loaded the data, but now we are locked into enforcing a specific rule that will change again and cause an issue. Chances are this change would cost about $250k and may have other issues downstream. 2. Enforce some governance on the consumption of the data. We could share with all the possible downstream consumers of this data the insights found to see if they are effected. What would the cost be? In some cases small. In other cases big. ,syne now we have to change multiple downstream jobs. Or maybe the required change does not effect the other groups and they need the data as it is. 3. Do nothing. Is there a way to quantify the impact? Is it worth the money and continued delay. I had a great Cleint who could boil a situation down to how many customers and how much money. He saved his organization millions of dollars not chasing down what were small anomalies with limited impact. So happily I believe this comes down to proper governance and context. How would you handle is issue?

Changing Your Point of View

Many times I find myself trying to explain something saying that I believe that is very simple and often it is viewed as more complex.  I was in a conversation with Graham last night as we were reviewing some stored procedures created a couple of years ago and he said "Jim is right this really is very complex".

One of the things I get out of this comment is that often if I only see something as simple, it does not give the right perspective to the nature of the issue that is at hand. When we do this with technology, we often overlook the complexity and this will often cause us to use the wrong approaches in development, management, testing or support.

To take it in a slightly different than technical direction, think about the difference between a project or a program.  I once was involved in a project audit and the banking customer and one of the biggest observations was had was that when the project started it was small and manageable as a project.  Somewhere in the project there was a change in the nature of the project (system, scope, interfaces, business model) and the project managed these with changes through a CR process, but there was no ability to realize that this project had really morphed into a program that needed multiple releases.  The findings really showed that if the perspective had changed there would have been a better chance to generate a successful conclusion.

These examples really drive home the idea of the difference in how you view or discuss the problem can have in this case a negative effect.  The same is true that if we can find a way to always be challenging our viewpoints and basis of understanding, we have a great chance to help ourselves and others be able to grasp the scope or nature of the issue at hand.

Ohh the power of words.

Data Governance Part 10 Introducing Data Governance

Successful introduction of data governance is really key to making the overall project successful.  The activity of data governance in practical terms is really not new to most organizations but the word is new.

Most organizations have created discipline around the rules governing who adds and changes data and data definitions in a single system.  An order entry system has all kinds of rules and discipline about who is authorized to make changes in the data definitions and rules.  Knowledge about how these disciplines work for these systems is key to making data governance work for the data warehouse.  The difference with a data warehouse is that the data provided comes from multiple systems.  The responsibilities must be created out of the existing organization. 

Before we add complexity of conflicts to the data definitions, a great first step would be to find out who are the data stewards for the systems feed the warehouse.  In many cases this responsibility has been defined and that person will likely be the identified data steward.   I think an important first step would be to identify these people in a data governance data base.  

Let us take an example from health care, wait time is big issue and the definition has provoked much discussion.  The important first step is to identify who are the data stewards for the existing tracking systems for the various systems tracking wait time.  At that point, we then can initiate some discussion with this group about rules and definitions.  Without this dialog with people with knowledge and responsibility, no progress can be made.  Often we get distracted by the tools we can use and spend too little time working with the key data stewards. 

In the context of a longer term development of data governance, we need to be very careful to build on what exists within the current organization and acknowledging the roles of key people.  What works in one organization will not work for another.  We need to carefully design a process that fits with each organization.  

Data Governance Part 9 Data Quality Story

About a year and a half ago my wife took out a credit card from a major US department store to obtain a big discount on a major purchase.  Although there were a few wrinkles in paying the bill. it worked out fine.   She never used the card again but about two months ago we got a bill from them for a store we had never been in.  I called up to inquire and the customer service person looked things up and said it was clearly not her signature and she would refer it to the fraud department but it would take a while.

About a month later we got another bill with delinquency charges on the bill.  We called up again and was connected with the fraud group.  They said it was not fraud it was a mistake.  A person was at the store in this place and did not have the card so gave the last four digits of the social security number and an account popped up.  As background, we are from Canada and we have a Social Insurance Number and my wife had to give this to get her credit card.   The last four digits on my wife's card was the same as this person''s four digits on the social security number.   Eventually it was all cleared up but I am willing to bet this problem will affect my wife's credit rating.

So here we have a data quality issue which becomes a business issue because we will think twice about shopping in that store again.  How many of these customer service problem are causing people to go somewhere else to shop?  The most precious commodity of every business is their customers and how quickly they lose our trust.

Another data security issue is that, in Canada, a business cannot use our Social Insurance Number as a means of identifying us.  The only people who can use it are the tax people and the social security people.   Interesting how anybody can ask for your SSN in the United States.  

I wonder how often in all our businesses, data quality becomes a customer service issue.   

Data Governance Part 8 Is Data Quality an IT Issue?

I just read a very provocative blog about whether data quality is an  IT issue and the author has a good point.  See http://www.dataqualitypro.com/data-quality-forum/post/667593

Of course data quality is a business issue but that does not mean that IT is not intimately involved.  Often the business rules specified by the business are not impemented correctly and sometimes the data validation routines are incorrect.  There are numerous other examples, but in the end the business must make sure that these errors are corrected by IT.  Often these errors do not show up during testing but later when the application is being used.

Often the phrase that data quality is a business issue is interpreted as IT not acknowledging their role.  Nothing could be further from the truth and the business must work with IT to correct the data quality issue.  Often the responsibility is shared and must be resolved by the groups working together to resolve some very complex data definitions and business rules.  Effective data governance is an effective team effort with everybody working together to deal with issues rather than placing blame or pointing fingers.

Data Governance Part 7 Data Stewardship

One of the key ingredients in data governance is the concept of data stewardship.  Every project should be familiar with the concept and introduce the concept on all their projects very early.  I think it is a great way to get started on data governance and will get great support from the business owners of the data. 

I must give Robert Seiner some credit for these ideas because has written some excellent material on this subject.  You can see his work at www.tdan.com

Data Stewardship is the formalization of accountability for the management of data resources.

I have asked several people on various projects recently if they knew who the owner of various data resources was on their projects and with a little thought each one said yes.  These people are the informal data stewards and our thesis is that they should be recognized formally and explained their role.  A role they are already fulfilling on an informal basis.

The next step is to create metadata for the data steward which contains the names of the stewards and the data they steward.  Seiner calls this the Stewardship Repository.  In addition the responsibility should be written in their job description.  This action simply formalizes an activity they already do.

The great news is that we now know the answer to the question "Who owns the data?"  We then know who to go to if we have questions about the data and its status.  I bet everybody in the data warehousing business would welcome a place to go to find out who owns what data. 

My suggestions is that early on in every project the Business Analyst be assigned the responsibility of adding to the Stewardship Repository.  I am sure its existence would save the Business Analysts a significant of time.

This is the first step in data stewardship but a really important and relatively simple step.  I invite your comments. 

Collaboration is More Than Just Talk

As most of you who follow our blog know, Project X's RapidBI Approach and Platform is linked and depends very much on Agile Development and Real Collaboration.

The challenge with the word collaboration is that often it is just talk.  I have had the opportunity to work with someone who knew how to collaborate.  He is also a Lean Six Sigma guy and that doesn't hurt either.  It was a real pleasure.  We had some bumps coming up with common frameworks, we are both type A personalities and that was often fun.

But after about 1 week I really felt he was a collaborative partner.  We got to a comfort level I felt that allowed for often open or frank discussion that hopefully he would agree that neither of us used to our advantage when things got tough.

Exit that phase in the project/program and we had new people come in.  Sadly we can not get past the 'Just Talk' phase of collaboration.  This is tell me what I need to do, I will do it and then throw whatever back at you.  Sadly not even jumping back onto our collaboration platform helped us break through.  I just did an audit of the collaboration environment and there is nothing there.

Funny how we are spinning.  Less talk, Way less oversight meetings and lets get together and do it.

Data Governance Part 6 The Role of IT

I would like to discuss now the role of the IT folks in the data governance process.  In my previous blogs, I have emphasized how important it is that the process be business led.  However the IT folks have a very important role in data governance.  The role is to provide assistance and support in implementing the decision of the governing body.  In addition the IT folks have a responsibility to raise issues that require decisions.

One of the key responsibilities of the IT folks and the business is to maintain an open dialog on issues.  The challenge for the IT folks is to express the issues in plain language as opposed to talking to IT speak.  IT folks have a great tendency to talk in slang and short forms because they get tired of repeating the same words over and over again.  I think it is the responsibility of the business people to call them on this whenever it is used. 

In addition to the obvious reason of understanding each other, sometimes the IT folks often do not know the meanings of some of the terms they use.  Another thing is that some words lose their meaning through overuse.  For example, the word "system" really does not have a very specific meaning any more.  Let me give you other examples: program, software, web 1.0, web 2.0, SOA, and on and on.  However often the business people do the same thing.  Some of the worst offender are the defense, the aerospace and telecommunication industries.  These groups use so many short forms one would swear they are speaking another language. 

I am emphasizing this understanding as being important because I think it is key for effective data governance.   I will continue developing ideas on governance in future blogs.