Posts Tagged ‘development’

Open Letter to Gartner

Thursday, February 4th, 2010

Dear Andrew White,

Thank you for your comments in “Something beyond MDM is coming your way – would MDM 2.0 fly?” and starting the discussion to expand the definition of MDM to include data integrity, data quality, entity resolution, matching, data integration, governance, metrics and analysis. The topics discussed should also include work flow (management of data and analysts), translation management, data structuring, data profiling, duplication removal, data change management, verification contact management, etc.

The MDM and PIM software industry needs to take a step back to understand actual day to day business requirements of data management to achieve Master Data Quality. Lesson one is that data is created and supplied by many sources in many different formats at various quality levels. Data is created by engineering, submitted by integrators, manufacturers and suppliers. To add to the complexity of the information flow, data is introduced into businesses systems in different departments (engineering or purchasing or maybe plant from maintenance) with different data requirements to meet the needs of that job function. Now the next dynamic is mashing new data to existing legacy data in a number of systems to ensure no duplicates are created, managing obsolete / recommended use and functional equivalents. The old philosophies of a PIM or MDM software to “hold, provide search functionality and maybe a shopping cart” isn’t going to meet the true requirements of the new definitions of Master Data Management.

To meet the new definitions the MDM or PIM software needs to provide horse power to electronically and intelligently processing data to identify exceptions for manual intervention by an analyst. Data should be processed one time to ensure that the data record will be enriched to meet the requirements of the enterprise and then the record is moved to a maintenance program (managed also by the MDM or PIM software). The processing of data needs to be efficient and cost effective, from my perspective the cost of data management should be covered by the cost saving achieved by MDM management.

I look forward to the discussions as the definition of MDM is expanded to include data quality, data governance, data provenience as the software industry provides the intelligence, functionality and business processes to cleanse, enrich and management data for my client to ensure their ability to make confident business decisions based on data integrity and accuracy.

Here is to the future of PIM and MDM!

Jackie Roberts

View Jackie Roberts's profile on LinkedIn

Tags:, , , , , , , , , , , , , , , , , , , ,
Posted in Jackie Roberts | 2 Comments »

New Data Management System Implementation Common Sense

Friday, January 8th, 2010

With the ever increasing emphasis on finding ways to reduce cost, one of the clear targets is IT and more specifically data management systems. On the surface it can seem like there is real fat to trim, and many times this is true. But it is easy to become lost in the details and eliminate or negate some of the potential savings. Some of these ideas may seem obvious but are often forgotten. The evidence is clear with missed timing and over budget issues seen.

If we’re talking about a large company then inevitably with this new system comes the monolith project with whole organizations of people and processes, projects and documentation. The compulsion is to be sure that everyone, everywhere who has any relationship to it has their input and their needs accounted for. Along the way, the cost of implementation and other peripheral indirect costs have likely negated a great deal of at least any short term savings. Not to mention the potential increase in continuous maintenance costs and loss in performance. These are a few things I’ve learned from experience and I welcome yours.

Always have a specific objective when planning for development or evaluating software to purchase that overrides all others. Start with something like a mission statement, “We need this new system for….”

Determine the Real Needs. Try to separate the “must haves” from the “nice to haves”. Bells and whistles are great but there needs to be a true benefit. Seek a balance between development time, software performance, hardware performance and user experience. I always try to put special emphasis on the user group which stands to benefit the most. Having many users who can do their job faster and more efficiently can add up to real savings versus the few users who have a special need which bogs down the project and performance.

Change is inevitable. If some requests for additional features come along, evaluate them against the mission objective. There is nothing wrong with listening and investigating ideas for project add-ons as long as the benefits outweigh the costs in time and money, but there needs to be a limit or you’ll never complete the project. Good ideas can always be implemented later if it makes sense then you’ll have the benefit of the research already done, but be quick with the research. Evaluate the impact for doing it now or waiting. Here are some good questions to start with: 1) How much more money?  2) Would this be faster/cheaper for programming to do it now versus waiting and doing a more complicated enhancement?  3) Is the impact to the users great enough to warrant it?

Know the roles. Good ideas can come from anyone. Every project must have a project champion who makes the final decisions (and live with them) and also eliminate roadblocks. You need a user advocate who has done the job and knows what it takes. Have programmers who possess both talent and vision, not just code crunchers, and listen to them.

Have good documentation, and “Good” is subject to interpretation. This is another area where the KISS principle is very often not utilized. If you have to hire ten people to sit in meetings just to maintain your documentation you’ve probably overcomplicated it and certainly increased your project cost. I try to start with these principles:

  1. Document the people on the project and their responsibilities. Let there be no question as to who does what.
  2. Everyone who has a job to do needs to understand what they need to do and have the documentation to reference.
  3. Keep the language simple. Focus on getting the point across. If it takes a rocket scientist to understand it you’ve failed.
  4. Of course, document the issues, decisions made, by whom etc. but be sensible. Document enough to cover for the “he said/she said” but content is most important. No bonus points for flash.
  5. Know who is supposed to have what done and when. Another obvious one here but I see too often where target dates are determined top down with little or no thought to cost or the tasks. Don’t let the tail wag the dog. Pushing hard to get the job done is fine but be realistic. Listen to the people who know before making bold predictions.

Tags:, , , , , , , , , , , , , , , , , , , , , , , , ,
Posted in Carl Hamlett | No Comments »

Decision and decision

Tuesday, October 6th, 2009

The difference between a Decision and a decision is simple. A Decision spelled with an uppercase “D” is one based on data, information and real-life experience. A decision spelled with a lowercase “d” is one made without data, information or a real-life experience. All too often I have seen decisions based on an individual’s feelings or opinions of a given situation. It makes me shake my head. In some cases, a business will use an algorithm or spreadsheet with embedded formulas to “choose” the best decision based on a set of desired requirements and associated weights applied to each requirement. For certain decisions, this might be the most appropriate way to assess the situation. For me, working to develop web-based software applications, it just doesn’t work.
The most common method of decision making during a development cycle I have come in contact with is the “committee” driven requirements analysis. During this process a group of usually high level managers (far from end users) sit down and work their way through a spreadsheet of requirements to decide which ones should be included in the next six-month iteration of development. In my experience, the only information included in the requirement column is the perceived expected behavior or outcome of the given feature or change. The end of this type of development cycle is usually followed by hundreds of hours of testing and arguing about how each feature should work, how it actually works and how we ‘thought” it would work. As well as two strokes, three heart attacks and a combined three square inches of newly exposed scalp for the male members of the team…

Every day I make decisions. Some turn out to be the right ones. Some turn out to be horribly wrong. Since I accepted the role of product manager rather than simply a project team member, I have put a great deal of thought around decision making. I ask myself questions like: “What information do I need to make a decision the right one?,” “At what point do I have enough information to make the decision?,” “Does the outcome of each decision I make effect the remainder of the product launch in a positive way?” I still can not answer all the questions I have about decision making. However, I have used the following principles to aid in making the right decision most of the time:

1.) Make lots and lots of small Decisions. When you send your developers off on a mission to complete a large section of code or forge an entire revision to an app in one shot, there are inevitably a lot of decisions that have to be made along the way. If your development team has to make these decisions on the fly, against an imaginary timeline, there is a large chance the decisions will be made without all pertinent information. It’s more likely each small Decision will be the right one if you use all the information available from the complete team at each point a decision is required.
2.) Keep the communication channels open between developer and subject matter experts. I recommend daily touch points of less than 15 minutes. Meetings are expensive, time consuming and often attendees are never prepared. I prefer discussions to take place at the programmer’s workstation while he or she is working on changes. This allows demonstrations of current and expected behavior to be shown immediately. Real information and real code turns into a visual aid. It is important all team members understand the purpose is not to meet the schedule. The real purpose is to launch an application people love to use. I might go as far as saying it should be expected that as you move from design to development, you’ll need to make lots of little changes along the way. I question any development cycle where there is little difference between the original designs and the product at launch.
3.) Test, Test, Test. After each Decision there should be some time spent to test it. Testing does not have to be a project in itself. Testing should be performed by both developer and the team member who is in the best position to interpret what will and will not benefit the end user. Testing at each available opportunity is essential to minimizing the amount of change required after a bad decision is made. For example, if a change is made and not tested, each change implemented from that point forward could require revisiting if it’s found the original change was in error.

These principles also contribute to a pleasure filled work environment by allowing each team member to work on what they love. Development does not have to sit in endless conceptual meetings, nor does the product management team need to wait months or weeks to debut new features. The three principles I illustrated above can and should be applied to any development scenario. Using these principles to govern product testing and design reduces our development cost and gets our product to users faster. And in the end, that’s what it’s all about.

Tags:, , , , , , , , ,
Posted in Chris Roberts | No Comments »