And...I'm Safe.

It's good to know that according to the big analyst firms, the key areas I'm focused on are going to continue to be the top spending areas in this down-turned economy.

InfoWorld reported in an article here, about the findings of several big IT analysis firms what are supposed to be the top 5 spending priorities for the next year. Not surprisingly, cloud computing and business optimization were up there.

When the economy isn't doing well, I often get the question about how my business is doing. The great thing about helping companies do business better is that tough times are great motivator in the way that years of plenty are not. Simply put, if they are making lots of money anyway, it's hard to get people to focus on the costs involved. When they aren't making money so easily, all of sudden they are very interested in what things cost.

You can apply this to your own life too. Are you in feast or famine? Should you be making hay while the sun shines, or playing frisbee? Having billable work is no excuse to put off training, writing, and exercise.

Preparing For Multi-site Engagements

I've spent quite a bit of time in the last several years living and learning with the challenges of doing multi-site projects. From offshore development where I managed teams operating between the US and India, to near-shore development with teams on both coasts of America, to smaller engagements with 6 people in 3 west coast cities. I've had successes and not a few glorious failures. It's the pitfalls, missteps, and screw ups that helped me learn the most.

Recently, I was asked to give some feedback on the things that have the most impact to new multi-site engagements. This is a pretty common request these days and I've since written down my thoughts so I could present them more consistently. This post is a very succinct summation of the big ticket items.

Naturally, much of this advice would be tailored to the specific circumstances and players, but the items discussed in the post are all generically applicable. If your situation involves working with teams in India or Manila or Slovenia (as examples), you'd want to get some specific tips on dealing with those cultures. This is no different than if you will be working with any of the Native American nations or in Silicon Valley where there are special considerations. Always get the heads up so you can be sensitive to the culture in which you'll be working. But those are for other posts, on with the show.

My personal guide is an ordered list I cheekily refer to as the Four T's. In order of impact they are Trust, Time, Transparency, and Talking. I'll discuss each a little to explain what I mean.

Building and maintaining trust is the single most critical thing that can impact your engagement. It is extremely easy to take this for granted, especially since it seems so obvious. In reality, we rarely address issues of trust head-on in the corporate world, but they become very important when you don't have face-time to rely on in the relationship. Nothing builds trust as fast as personal bonding time, nothing destroys it faster than a lack of transparency. Once trust becomes compromised, every other facet becomes harder and more risky. Without trust, communication become s suspect and morphs from a tool into a weapon.

If you want to earn trust, get some face-time. Obviously, in the real world is best, but lacking that, get on a video chat. You have to be able to read and see body language. You have to find a way to bond and see each other as people not resources. You have to allow everyone to take the measure of everyone else and to fill in the mental picture that they'll remember and substitute into every other conversation regardless of media.

Recognize up front that coordination among parties in different physical locations is inherently going to take more time. It takes more iterations to verify directional correctness, ensure quality, and declare accomplishments. Everything just takes more time. Stop trying to pretend this isn't the case or even to minimize this to act like it won't. Just prepare and plan for the impact, embrace the reality when it occurs, and don't get cocky when things are going smooth and you think you can tighten up.

When it comes to operating transparently, make sure you are delivering messages properly. Any directional messages should be disseminated with the whole team at the same time. When possible, do all messaging to the entire team at once. Then reserve your smaller leadership group for issue resolution and check-pointing. This can feel unwieldy at first, but the dividends it pays in trust will more than make up for it. If you are suffering from any trust issues, this can be the only chance at repairing the damage and pulling the team back together.

Lastly, don't under-estimate the power of Talking. Emails do not carry tone or intent very well. They aren't very transparent so they wear down the trust and are the easiest road to miscommunication. This is not to imply you don't write things down. On the contrary, always follow up your conversations with a written summary of the talking points decisions, action items, etc. But as much as possible carry your meaningful conversations over voice. If you can add the element of your face and body language via video, this is all the better.

These are important things to consider as you move forward but the attitude in which you apply each of them is also critical. Remember that you aren't planning for efficiency, you plan so that you'll recognize the problems that WILL occur and fix them without a total collapse. This is similar to how automobiles are designed. Some years ago, some automobile companies made amazing and powerful engines but you had to take the whole thing apart to change the oil. Other companies came along with designs that weren't as efficient to run, and were a little more expensive to design and build. But the oil change was a simple thing anyone could do for a few dollars. Ultimately the more successful designs were those that made it easiest to deal with the challenges that were certain to arise (changing the oil) as efficiently as possible instead of trying to optimize for performance or build cost.

The last tip I'll offer in this post is about quality and standards. When doing multi-site engagements that involve parallel efforts or multiple work streams, consider separating the oversight for quality or standards enforcement into an isolated group. Leaving the oversight functions within the different operating units allows disparities in enforcement or standards to creep in. This often is construed as unfair advantage or favoritism or something equally nefarious. Left within each group this disparity is pretty unavoidable and is a very subtle disease that can do a lot of damage when left unchecked. Making a distinct group responsible for these functions will help avoid this issue and its variants. It can also serve as a single neck to choke when trouble does arise.

Don't forget that tips like these aren't any use if you don't treat people with respect and act with integrity.

Master Data Management

Recently I had the pleasure of discussing with a prospective client the bulky subject of Master Data Management (MDM). In this situation the client was considering a variety of MDM solutions and wanted some specific direction into which technology/vendor to choose from.

Now it is no secret that I tend to favor Microsoft products but in this case the platform already in place was Oracle so naturally, I wanted to give them more general advice instead of just pushing MS MDM.

There are quite a few upfront activities that must be done regardless of which products you are going to use. I've listed some introductory efforts that need to be done earlier in the process and that can be done before production selection.

• Governance
  To get the ball rolling, you really need to figure out what data you are talking about, where it lives, who thinks they own it now, and what organization you need to address this effort. Here are some suggestions on how to make this go smoothly:
  
  
  1. Identify External Data Ownership
     Often there will be multiple owners identified for the same data. Being able to identify these different uses in their various applications is a significant lever used throughout the rest of the process. Without a clear understanding of where the data is currently 'owned' and its criticality to various applications, mis-matched expectations will cause problems.
  2. Formalize Ownership in MDM
     This often requires significant negotiation and compromise from the various stakeholders. In organizations where the inter-organization trust level is high, this is more straight-forward. In some environments, only a top-down directive will accomplish this. Whichever tactic is used, establishing formal ownership is a prerequisite for success.
  3. Identify Data Domains
     This sounds a lot easier than it always ends of being. Attributes utilized by disparate systems often have subtleties in their definitions which must be accommodated. Being able to provide synonym mapping and transition approaches is imperative to keeping comfort levels high between organizations.
  4. Formalize Domain Administration Process
     Having an established (and hopefully standardized!) set of processes to perform CRUD operations on domains can take the stress out of relationships where trust levels are sub par between applications.
  5. Establish Organizational Governance
     This is often rolled up into Change Management or a similar phase, but in reality needs to be an ongoing activity. These organizational groupings will allow for escalation procedures, conflict resolution, and increased visibility into the data lifecycles.

Once you have the basic framework to talk about data ( and who owns it, how it gets maintained, etc. ) you can then delve into the specifics of the data.


• Model Dimensions
  If governance is properly addressed, this should be a fairly straightforward exercise for data architects. They'll go through some steps similar to the following:
  
  
  1. Identify Dimensions
     What data are you really talking about? You need to pick a single name for each domain. Sometimes the same type of data is called different things in different places. You have to formalize on a common taxonomy.
  2. Identify Consuming Applications
     There may be downstream consumers beyond the currently perceived data owners. Make sure you understand the data lifecycle and flows so you can estimate impacts properly.
  3. Identify Entities Per Dimension
     Make sure you flesh out the taxonomy down to the most granular level necessary. The more detail you include now, the more hours saved later.
  4. Identify Entity Attributes
     This is a critical step that is often treated as a second-class citizen. In reality, it is a key driver. Without precision about attributes, the potential values and rules (which come next) can't be properly defined. It also means your estimates will be incorrect.
  5. Quantify Attribute Values
     This is only as important as the complexity of the data rules (which come next) and the accuracy of your rule implementation estimates need to be. If your sources have this well defined, it should be straightforward to ensure this is comprehensive.
  6. Identify Data Rules
     This is sometimes referred to ambiguously as Business Rules which is very imprecise. Here we are speaking not to rules governing operations or activities (hence the term Business) but instead the states, lifecycles, and value cohorts for entities and domains.

As you can well imagine this is a significant undertaking for any organization, and can be done in a technology agnostic way. Once you've identified and quantified this information, you can begin to look at transition plans, data flow planning and infrastructure. These are very technology and environmentally specific.

As the proverb states: "Measure twice, cut once."

Serious Confusion

In my reading, I came across an excellent post about the estimation process for software development.  The author (Serious Confusion) does a solid job of summing up his views with style.  I encourage you to check it out here.