In the Field with our Experts

Making It Fit

By Stephen Putman, Senior Consultant

I've spent the last eighteen months at clients that have aging technology infrastructures and are oriented to build applications as opposed to buying more integrated software packages. All of these organizations face a decision which is similar to the famed "build vs. buy" decision that is made when implementing a new enterprise computer system - do we acquire new technology to fulfill requirements, or adapt our existing systems to accomplish business goals?

Obviously, there are pros and cons to each approach, and external factors such as enterprise architecture requirements and resource constraints factor into the decision. However, there are considerations independent of those constraints whose answers may guide you to a more effective decision. These considerations are the subject of this article.

Ideally, there would not be a decision to make here at all - your technological investments are well managed, up-to-date, and flexible enough to adapt easily to new requirements. Unfortunately, this is rarely the case in most organizations. Toolsets are cobbled together from developer biases (from previous experience), enterprise standards, or inclusion of OEM packages with larger software packages such as ERP systems or packaged data warehouses. New business requirements often appear that do not fit neatly into this environment, which makes this decision necessary.

Aquire New

The apparent path of least resistance in addressing new business requirements is to purchase specialized packages that solve tactical issues well. This approach has the benefit of being the solution that would most closely fit the requirements at hand. However, the organization runs the risk of gathering a collection of ill-fitting software packages that could have difficulty solving future requirements. The best that can be hoped for in this scenario is that the organization leans toward obtaining tools that are based on a standardized foundation of technology such as Java. This enables future customization if necessary and ensures that there will be resources available to do the future work without substantial retraining.

Modify Existing Tools

The far more common approach to this dilemma is to adapt existing software tools to the new business requirements. The advantage to this approach is that your existing staff is familiar with the toolset and can adapt it to the given application without retraining. The main challenge in this approach is that the organization must weigh the speed of adaptation against the possible inefficiency of the tools in the given scenario and the inherent instability of asking a toolset to do things that it was not designed to do.

The "modify existing" approach has become much more common in the last ten to twenty years because of budgetary constraints imposed upon the departments involved. Unless you work in a technology company in the commercial product development group, your department is likely perceived as a cost center to the overall organization, not a profit center, which means that money spent on your operations is an expense instead of an investment. Therefore, you are asked to cut costs wherever possible, and technical inefficiencies are tolerated to a greater degree. This means that you may not have the opportunity to acquire new technology even if it makes the most sense.

The decision to acquire new technology or extend existing technology to satisfy new business requirements is often a decision between unsatisfactory alternatives. The best way for an organization to make effective decisions given all of the constraints is to base its purchase decisions on standardized software platforms. This way, you have the maximum flexibility when the decision falls to the "modify existing" option.

photo by orijinal via Flickr (Creative Commons License)

---

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. He is the co-author of The Data Governance eBook, available at information-management.com.

Understanding Where Our Work Comes From

By Mary Anne Hopper, Senior Consultant

I’ve written quite a bit about the importance of establishing rigor around the process of project intake and prioritization.  If you’re sitting there wondering how to even get started, I believe it is important to understand where it is these different work requests because unlike application development projects, BI projects tend to have touch points across the organization.  I tend to break the sources into three main categories—stand-alone, upstream applications, and enhancements.

Stand-alone BI projects are those that are not driven by new source system development. Project types can include as new data marts, reporting applications, or even re-architecting legacy reporting environments. Application projects are driven by changes in any of the upstream source systems we utilize in the BI environment including new application development and changes to existing applications. Always remember that the smallest of changes in a source system can have the largest of impacts to the downstream BI application environment. The enhancements category is the catch-all for low risk development that can be accomplished in a short amount of time.

Just as important in understanding where work requests come from is prioritizing those work requests.   The three need to be considered in the same prioritization queue—this is a step that challenges a lot of the clients I work with.  So, why is it so important to prioritize work together?  The first reason is resource availability.  Resource impact points include project resources (everyone from the analysts to the developers to the testers to the business customers), environment availability and capacity (development and test), and release schedules.  And, most importantly—prioritizing all work together ensures the business is getting their highest value projects completed first.

 

---

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.

IT-Business Alignment: Let The Business Drive

By Caryn Maresic, Senior Consultant

Julia’s parents were planning a vacation.  Her mother thought Pensacola would be a great destination—she’s heard so much about the wildlife, especially the dolphins!  Her father wants to see the National Naval Aviation Museum and the Blue Angels.  Since Julia’s traveled extensively, her parents asked her to make all the arrangements.  While having dinner with them to discuss plans, she jotted down the following notes:

• Location:  Moderately-priced hotel close to water/sights.
• Budget: $3,000 for transportation and accommodations.
• Activities:  Beach and nature activities (Mom), science/historic sights (Dad)
• Duration: 10 days.

Julia felt honored that her parents trusted her to get the job done.  After doing some online research, she made all the reservations and met with her parents to review the reservations.  She eagerly awaited the look on her parents’ faces as they scanned the vacation itinerary and read through the glossy brochures.

“Hawaii?”, they said in unison.  “We didn’t want to go to Hawaii!"

"Honey, we chose Florida because we can drive there.  I don’t want to fly anymore.  Flying is such a pain,” Dad grumbled.

“I appreciate what you’ve done, Julia, but an old friend of mine lives near Pensacola and I was hoping to visit while we were there.” said Mom.

“But, Mom!”, exclaimed Julia, “You said you wanted beaches, dolphins, sunny weather.  Dad, you like science and history—what about Pearl Harbor?  You two can’t go to the gulf coast—what about the oil spill?”

What happened here is typical of what happens to IT projects all the time.  It’s easy to say that we wouldn’t do what Julia did.  Would we?  Don’t we oftentimes:

• Interview the business and record the requirements in an abstract way.
• Believe that the we can deliver something better than what the business asked for.
• Assume that the business lacks the capability to understand the technology.
• Fail to get all of the requirements.  Not exactly our fault, but still a problem.
• Neglect to keep the business involved in the process.

There has been a lot of buzz on IT-Business alignment of late, including this article on some specific companies that are going the extra mile: Beyond Alignment—as well as this one on lack of user involvement: Why IT Projects Fail: Lack of User Involvement.  Most companies aren’t as progressive.  The willingness to work together has to occur at all levels. Only when we let them drive can we deliver, if not what they asked for, then at least something useful.

photo by stevendepolo via Flickr (Creative Commons license)

---

Caryn has over 20 years experience in providing high-quality data solutions to clients in the areas of Business Intelligence, Data Warehousing and System Integration.  Caryn has expertise in across industries with an emphasis in Pharmaceutical, Manufacturing, and Insurance.  Prior to joining to Baseline, she ran her own consulting company.

The Role of Logical Data Models

By Caryn Maresic, Senior Consultant

Logical Data Models (LDMs) were the standard means of recording business rules and data definitions back in the ‘80s and ‘90s.  Business and IT partnered to learn the art of data modeling and 3rd normal form in hopes of finding a common ground to record requirements.  Over time, it became evident that in today’s fast-paced development environment the business doesn’t have the time to digest all the nuances in a data model.  It is IT’s job to gather information via interviews.  Many times, we skip the LDM task because we don’t have time and LDMs are too academic and we find ourselves asking…

Are Logical Data Models really necessary?  Yes!

LDMs drive BI design by defining business rules independent of physical implementation.  There are many tools (CA ERwin Data Modeling, Embarcadero Technologies), and techniques (UML, IDEF, Bachman) in use today. To illustrate the difference between the benefits of a PDM and an LDM, let’s look at an example:  Customer/Address relationships.

The PDM above (created using) supports many Customer/Address business rules, but it does not tell me the Customer/Address relationships as defined by the business.

In contrast, the following LDM is more rigorous and definitive:

What does the LDM above tell me that the PDM did not? 

• There are two types of Addresses – Physical and Mailing.
• The Customer Bill To Address can be either a Physical or Mailing Address
• Customer Ship To Addresses must be Physical Addresses.
• Every customer must have a Bill To Address.
• A Customer has zero, one or many Ship To Addresses.

All of these relationships can be implemented using the PDM, but they aren’t dictated by the PDM.  The LDM explicitly defines each relationship and prompts us to ask better questions of the business, such as:

• Are there any Customers who do not have a Bill To Address?
• Are there any Customers who do not have a Ship To Address?
• When there are multiple Ship To Addresses, how do you know which one to use?
• Are there any Customers who have more than one Bill To Address?
• Do you know of any upcoming business initiatives that might change these rules?
• Was there ever a time when the business rules were different?

The answers to these questions may require changes to the model, but without the LDM, we may not have asked the right questions!  The best part about the LDM is how valuable it is to the rest of the development process.  It will be used in production of training materials, test plans and test cases, data profiling and migration efforts and, finally, physical database design.

---

Caryn has over 20 years experience in providing high-quality data solutions to clients in the areas of Business Intelligence, Data Warehousing and System Integration.  Caryn has expertise in across industries with an emphasis in Pharmaceutical, Manufacturing, and Insurance.  Prior to joining to Baseline, she ran her own consulting company.

Consulting Terms of Engagement: a Readiness Checklist

By Carol Newcomb, Senior Consultant

Having worked at least half of my professional life either with consultants or as a consultant myself, I need to offer some practical advice on increasing the probability of success on a consulting engagement.

Remember, a consultant is just another tool in your management toolbox that provides either the leverage (expertise/experience) or the hard skills that you and your staff are missing today.

There are three main reasons to hire consultants:  1) you want coaching from expert advisors to mentor your existing team and provide tactical advice; 2) you don’t have the skill-sets that you need (ETL programmers, software/hardware experts, etc.); or 3) to provide frameworks and processes to build and sustain ongoing programs (like business intelligence or data governance).

Regardless of the type of consulting engagement, your staff need to be on board with the presence of consultants in their midst.  Ask yourself, as the sponsor, some basic questions:

• Have you explained to your team what the purpose of the consulting engagement is intended to achieve and their role in making it successful?
• Are you as a sponsor willing and able to provide authority for the consultants on the ground?
• Are you willing to spend time with your team and the consultants in the same room, to work out issues, questions, strategy and tactics as they evolve over time?  Don’t think you can just punt and run.
• Do you have committed resources on your team to help with knowledge transfer?  This is not an “all other duties as assigned” task for your staff.
• If consultants will replace or supplement existing staff, is your staff aware and comfortable with this?  This will inevitably become a problem if the expectations are not managed upfront.
• Are IT and Business ready to start working together?
• Do you have true business users and are they ‘on board’ with your project?
• Is there a way to prioritize issues as they come up?  One thing all consulting engagements do is bring to light an unsightly set of issues that become obstacles to progress.
• Can you be honest about your culture? Are their repeated patterns or behaviors that could sabotage a key project?
• Can you comfortably “park” issues that are not showstoppers in order to move ahead despite them?

There are probably many more items I could include on this “preparedness checklist.”  The point is that consultants can often be perceived as disrupting the natural order of things.  Either you, as their sponsor, will need to introduce them and guide them through the organization to ensure they are effective, or you need to clearly delegate to your staff what the expectations are for them to do the same.  If technical knowledge transfer needs to occur, don’t just assume it will happen.  I have seen too many consultants spend the first few weeks twiddling their thumbs either because they don’t have access to key systems, or they don’t understand the environment and haven’t been provided any documentation to work with in the meantime.  How much time will you allow for consultants to become proficient?

If the consulting engagement is to collect facts, conduct interviews, summarize findings, provide best practices, roadmaps or assessments then make sure they have a political lay-of-the-land upfront.  Otherwise, they will attend meetings they have no context for, they will assume things that may be incorrect, and they will be off-target in their recommendations. Also, many consulting firms sell their methodologies as separate and packaged products. If you expect your consulting firm to transfer its intellectual property as part of the engagement then your consulting contract should stipulate that. If you have secured the funding to bring consultants into your organization, you need to ensure that the project is a win-win.  The risks to you are probably larger than to the consultant group, because at the end of their engagement, they go away.  A good consulting firm will have ensured knowledge transfer along the way, but your staff carries some of the responsibility for that, too. 

If you’re considering or starting a consultant engagement, here are a few things to consider:

• Is your department/division receptive to advice or change?
• Are department heads, directors and managers on board with the engagement?
• If ‘best practices’ are recommended, does the department have the appropriate technical tools and agility to put them into practice?
• Have you done everything within your control to ensure the success of this engagement?

If the answer to any of the above is NO, then reconsider your readiness, regroup with your staff, and discuss alternative strategies with the consulting group you are working with.

If you have an opportunity to change and improve your department, leverage the effort to instill that change.   You may not get more than one chance.

photo by mykpwedding 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.

A Plea to the Engineers

By Stephen Putman, Senior Consultant

I am a computer engineer. I have been a computer engineer for over twenty years. I know a lot of other computer engineers. I have seen many techniques for implementing Business Intelligence systems, with varying degrees of effectiveness.

I have a simple request of my fellow engineers:

Please stop designing functions into your analytical applications without input from your business users.

It is a simple request, one that should be easy to understand and implement. Unfortunately, I have seen many companies where this idea is central to the fabric of the IT organization. Non-business managers are confident that they know what the business needs, either through hubris or a soured relationship with their users. Functionality is designed and developed that bears little relationship to how data is consumed and used in the business organization, usually without regard for the cost of development and maintenance of the resultant structures.

It’s easy to determine that this is happening in your organization - you attend meetings where the following phrases are used with increasing frequency:

“I think this is done...”
“They will need this eventually...”
“We didn’t think of that...”

We live in an age where the Business Intelligence projects that are completed are frequently over budget, late, and do not serve the needs of business users (too many projects are cancelled or abandoned as well). Much of this failure can be attributed to communication issues between the business users and the system implementation team. The system team means well by trying to fill in the gaps, but this often leads to frustration, uncertainty, and design based on hearsay. They really should try to resist that temptation.

How much more effective will your system be if you ask your users what they want, instead of guessing or assuming you know better?

photo by Wonderlane via Flickr (Creative Commons License)

---

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. He is the co-author of The Data Governance eBook, available at information-management.com.

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.

Every Story Has a Beginning, a Middle, and an End

By Mary Anne Hopper, Senior Consultant

When not at work, I enjoy racing sailboats - sometimes day racing and sometimes offshore racing.  Last year while racing from San Diego, CA to Puerto Vallarta, Mexico, we spent a considerable amount of time drifting off of Cabo San Lucas in absolutely no wind.   In the middle of the night with no wind, conversation tends to drift to stories amongst the team on watch.  Call it a lack of sleep but some of my stories made complete sense to me but not to my two watch-mates.  So they told me, “Mary Anne, every story has a beginning, a middle, and an end – now why don’t you start over from the beginning?” 

That line has become somewhat of a joke since that day and night spent off Cabo.   But, one of the interesting places it plays in my mind is the BI Requirements process.   That process can be broken down into three steps – business, data, and functional requirements.  A beginning, a middle, and an end.   Starting at the beginning with business requirements sets the stage for what business questions need to be answered ensuring value is delivered.  Data requirements can be gathered to support those business questions.  In the end, that functional requirements can detail how to access that data. 

Oftentimes, I see clients start with a set of functional requirements with no idea of whether or not they can be delivered with available data or what business questions they will answer.   This approach can take the project down one of two paths.  The first is back-tracking back through the requirements process that inevitably takes the project team longer to deliver because they start over with each step backwards.   The other path delivers the functional requirement but only with work-arounds (logic built into reporting, extra spreadsheets, new desktop applications, and so on), also a costly alternative when others try to support or extend functionality.  Neither of these approaches deliver the needed business value with the agility required.So when you’re planning your next BI deliverable, remember that every story has a beginning, middle and an end.  Start at the beginning with the business requirement, work forward to the middle data requirements and then the functional requirement at the end and you’ll enjoy the success of a story well told.

photo by Gabriel Villena 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.

The Natural Order of Things

By Dave Gilbert, Vice President of Field Services

Recently, it seems that every conversation with prospective clients at some point degenerates into an exploration of how much things can be “parallelized.” I suspect that this is being driven by two primary opposing phenomena: (1) a backlog of BI needs caused by the economic stall, along with monumental budget pressures; and (2) the hyper-speed of new competitive business pressures. While I am a huge proponent of iterative and parallel development efforts, forcing unnatural acts in planning a BI initiative can be a slippery slope when taken too far.

I am an extremely amateur woodworker in my spare time, and this discussion reminds me of a lesson that I learned the hard way – more than once. A few years ago, I decided to build some bookshelves for my home office. Being a planner by nature, I spent sufficient time drawing and designing how I wanted my bookshelves to look. I measured books, knickknacks, and various other things that I wanted either functionally or on display (I suppose you could call those non-functional requirements). I drove to my local lumber yard and picked out some really nice hardwoods and hauled them into my shop. I then spent many delightful hours cutting, sanding, shaping, and staining the various components of my shelves. Because I had to build some jigs to gain the effects I wanted for my shelves, it was much more efficient to cut and route them all in succession before moving on to other components of my design.

Somewhere along the way, my wife (perhaps the most important requirements stakeholder) poked her head into my shop and noticed that the elaborate hardware I bought was functional -- but “ugly” -- and she would much prefer recessed hardware that would be hidden from view. Being all about user satisfaction, off to the lumber yard I went. Unfortunately, this seemingly minor requirements change left my shelves an inch shorter than required and sent me into a redesign cycle which never really translated from paper plan to end product.

The lesson that I learned the hard way – other than the obvious one about gathering all my requirements upfront and getting signoff –- was that by attempting to gain efficiencies in my cutting, shaping, and finishing process, I lost the opportunity for learning through practical experience with my end product, ended up expending more energy, and had considerable cost overruns. Similarly, attempting to put unnatural parallel paths too early in a BI planning exercise can eliminate valuable learning opportunities for the design and development teams, and forces rework on multiple work products - instead of just fully rationalizing your design patterns, making sure they are complete, and then using those to componentize and parallelize your work. It often takes a BI development team one or two cycles of development and testing to get their design patterns fully fleshed out and capture some of the more subtle requirements. Parallel efforts prior to the opportunity for this bottom-up learning only open the door for multiple rework paths, cost overruns and project risks.

As one client has described to me, they are in a continual prototyping mode, but they never get to the “sausage factory.” What they mean by that is that every project is handled as a one-off, and iteratively developed until it is ready for production. But they never capitalize on the benefit of their experiences by operationalizing their processes and then componentizing the workstreams into parallel efforts. Every organization is looking for the magic of the sausage factory, but this requires the discipline to put repeatable processes in place and not to force unnatural evolution prior to its time.

Photo by antwerpenR via Flickr.

---

Dave Gilbert is responsible for managing Baseline’s consulting teams and ensuring consistent high quality project execution to support our clients’ business needs. Dave brings over 20 years of IT system and data warehouse project management experience, deploying systems for both global 1000 and smaller e-business clients domestically and abroad. He has assembled and led multi-national development teams to deliver complex, scalable, analytic solutions that have assisted clients in establishing competitive superiority.