In the Field with our Experts

The Price of a Tube of Toothpaste

By Mary Anne Hopper, Senior Consultant

As you can imagine, I travel quite a bit as a consultant for Baseline.  Over my tenure, I have developed a standard routine for getting through the airport.  More often than not, things have gone pretty smoothly for me.  Until this week – my bag was pushed into the extra screening area where it turned out there was an over-sized tube of toothpaste that had to be thrown away.   How did this happen when week in and week out, I use the same bag for my stuff and always get through without a hitch?  Well, I deviated from my process.

You see, the prior week I actually checked a bag and was able to throw a full tube of toothpaste in the ditty bag and I never checked when I was packing for this week’s trip.  I deviated from my standard process.  If you’ve ever implemented a “small” or “low impact” change that has blown up an ETL job, changed the meaning of a field, or caused a report to return improper results, you know where I’m going with this.

Process is important.  Discipline in implementing to that process is even more important.  Am I proposing that every small change go through an entire full-blown project lifecycle?  Absolutely not.  But, there should be a reasonable life cycle for everything that goes into a production quality environment.  Taking consistent steps in delivery helps to ensure that even the smallest of changes do not result in high impact outages.  This can be achieved by taking the time to analyze, develop, and then test changes prior to implementation.  What that right level of rigor is depends on the impact of the environment being unavailable or incorrect.

So, what did I learn from my experience with the tooth paste?  My deviation only cost me about $3.50, some embarrassment in the TSA line, and an unplanned trip to CVS.  I learned I will no longer change my travel packing plans (whether or not I check luggage).  What can you learn?  There is a cost in time and/or dollars if you don’t follow a set process.  The best starting place is to work with your business and/or IT partners to reach consensus on that right level of rigor – and stick with it.

Photo provided by CogDogBlog via Flickr (Creative Commons License).

---

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.

Governance at the Turkey Fry

By Mary Anne Hopper, Senior Consultant

There is a long-standing tradition in our area for the annual turkey fry and it is the competition for 'Best Dish.' The first year we made awesome grilled artichokes and lost to boxed lemon squares (no, I’m not bitter). The second year, we deep-fried artichokes, wrapped them in bacon, and put them on a stick and lost to some chocolate cake monstrosity. The third year I walked in the door and was appointed to the judging team. How exciting—I would finally figure out how to win the contest. Well, guess what?  The host said there were no rules and to just pick something, and keep in mind that desserts always win.

Sound familiar? It probably does because this is how a lot of you determine what BI projects you’re going to work on. Here is a sampling of techniques I’ve heard from some of you:

• We pick what looks most interesting.
• The queue is prioritized based on the level of the requestor.
• [Insert name here] from the PMO decides.
• Prioritization?  Everything is the most important so we work on it all.
• If it’s not breaking, we don’t touch it.
• I don’t know how stuff gets done but my request always seems to be at the bottom.

I’m going to suggest to you this isn’t the most effective or collaborative way to manage your portfolio of projects not to mention that the business isn’t getting as much value as they could out of you. So how do you fix it? A good place to start is by developing a standardized and transparent project intake process for requests and prioritization. Build the process with your key business stakeholders and then stick to it—the first exception is the one that begins to derail your process. 

As for the ‘Best Dish’ award – not being a dessert person, the potato casserole won.

Photo provided by Pedula Man via Flickr (Creative Commons License).

---

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.

Repeating the Basics

By Mary Anne Hopper, Senior Consultant

It’s not like I spend my weekend and down-time thinking about work but some of the lessons I learn over the weekend apply to Monday thru Friday.  Case in point, my kids recently attended a racing seminar with an Olympic sailing hopeful.   He worked with them for three solid days focusing on boat handling drills.  Some of the kids wanted to know why.  His response – because you have to be able to repeat the basics the same way every time so you can deal with all the things that will be different every time (like wind velocity, wind shifts, waves, other boats, etc).

How does that relate to BI projects?   In order to deliver value to our business partners in the timeframe they expect, we have to be able to execute our projects repeating the basics every time so we can deal with the things that will be different every time.   I hope that sounds familiar.

Two great starting points are the project intake and requirements processes.  I use the phrase ‘starting point’ for a reason.  The intake process defines what work your BI team will be working on and in what order.  After those requests become defined projects, the requirements process (business, data, functional/application) then define what is going to be delivered to the business.  No matter how well defined the design and delivery processes are, the beginning of the cycle is imperative to success.  The table shows some examples of what process components need to be consistent and repeatable and what types of things are likely to change on you.

The Basics	What's the Same	What's Different
Project Intake	Request cataloging Prioritization	Business users Business priorities Resource availability
Requirements	Business requirements supported by data and functional/application requirements Artifacts Acceptance criteria Sign-off	Data availability Data quality Business users

This is a short example list and by no means all inclusive – there are numerous other examples.  The take-away is to understand that ongoing delivery success starts is dependent on the basics.  And nailing the basics with consistency will allow for more easily handling all the things that continue to change.

Photo provided by John Hopper.

---

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.