Leadership for Uniting Business and IT

Technology Innovation vs. Insubordination

2009-06-02T10:48:00.002-04:00

You have been hard at work on your latest technology innovation. This innovation can take your organization to a higher level of profitability or streamlined operation. You've been successfully making your case for your innovation across departmental and hierarchical lines. But there are obstacles in your way:

- your boss doesn't believe your innovation can actually work
- there is no room in the budget to accommodate your innovation in the short term
- your innovation would open up new lines of business, but your organization's senior executives will not examine a relationship between a technology component and a profit potential of these lines of business

You truly and strongly believe that your innovation can take your organization higher, but the obstacles remain. You take all of the "believe in yourself" advice to heart in order to "hang in there", but the frustration continues to mount. The message of innovation can be tough to deliver to, and be accepted by an organization. On the surface, it can actually appear to be insubordination if your innovation is not part of the "master plan" in the minds of your organization's management.

Before your frustration bubbles over, you may want to consider these points:

- Understand your organization's short-term goals
For the next three or six months, your organization might not have the capacity to handle your innovation. There may be a critical window for your organization to focus on what it is doing right now, and what it plans to do in the short-term. You must exhibit an understanding and acknowledgment of your organization's situation and direction, otherwise a perception of aimless wandering regarding your ideas may result.

- Understand the current climate
You don't really feel the below-freezing temperatures when you are wearing seven sweaters - cut through the layers and get in touch. Who really holds the influence cards in your organization? Where exactly is your organization feeling the pressure that your innovation might relieve? Are there any factors outside the organization responsible for this pressure? And how much do you really know about them? Find out!

- Understand and believe in your organization's long-term goals
You are part of your organization because you want the organization to succeed in its goals, yes? If you ask yourself this question, and any part of the answer resonates "no", then you have an internal conflict of interest that no amount of innovation (or insubordination, for that matter) can overcome. You will need to reevaluate whether your goals for seeing your innovation put in play are in alignment with your organization's goals after all.

- Believe in yourself via persistence, not arrogance
Continue to make your case, but back it up with tangible benefits that can be sold across your organization. Exactly where and how will your innovation help your organization's people to complete your organization's goals? If you can state the costs and benefits of your innovation with equal and increasingly strong precision, you can avoid the far less convincing "I'm just right about this" and "Trust me" selling tactics.

When you can understand and accept the above, you know that you will need to take your mounting frustration to task, and focus on finding ways to work with or remove the obstacles in your way. You then can work towards a realized innovation and avoid an insubordinate situation that may not be necessary.

One exception to the above: emergency or crisis of organizational survival. There's nothing like a true survival emergency for an organization to consider ANY idea, no matter how far afield the idea lies. If a true crisis like this exists in your organization, and your organization's culture opens up its pathways of reception, you can go for the straight sell of your innovation. What may be perceived as insubordination at the outset can be forgiven, just as long as your organization weathers the crisis using your innovation, and of course, you are right about the results.

Considering the Exception-Tolerant Organization in 2009

2009-05-13T18:47:00.001-04:00

After almost five months into 2009, how are things going for you and your organization? Well, I hope. But perhaps you now have to do more with less. Perhaps you need to find a new way to profit, keep the status-quo, or just survive. Perhaps it is time for your organization to become an Exception-Tolerant Organization (ETO).

Today’s management consultants and thought leaders preach the mantras of embracing change and embracing uncertainty. Being able to embrace change and embrace uncertainty are indeed important. But being Exception-Tolerant is about taking these embracements and bringing them into the practicality of day-to-day business. Being Exception-Tolerant is not about solely reacting to business events and then making on-thy-fly adjustments into your workflows and systems just to keep above the water level.

Being Exception-Tolerant is about anticipating these business events and proactively building workflows that allow both people and systems to adapt and adjust smoothly, sometimes within minutes or hours of the exception occurring. In current-generation software development tools, there are language constructs that allow you to anticipate the exceptions that may occur during processing, and build a framework to handle them. Since we can do this with software, why can we not create these types of constructs in our own business processes, and with our own people?

We can, but only if we have the facilities and communication channels to do so. An Exception-Tolerant Organization (ETO) has the Exception-Tolerant people, the Exception-Tolerant business processes, and the Exception-Tolerant technology to proactively execute during times of change, uncertainty, and exception.

Exception-Tolerant Organizations:

- embrace change and uncertainty while systematically executing their business

- build the communication pathways, business processes, and technology features to handle exceptions systematically

- emphasize their strengths and compensate for weaknesses by working together and communicating openly

- practice daily Risk Management

- do not tolerate waste, stifling of innovation, or inflexibility

And when ETO’s practice the above effectively, they turn out to be exception-al organizations, not exception-less. For if you are exception-less then you don’t stand out and cannot be exception-al in business.

Can your people, your processes, and your technologies tolerate the physical, logical, internal and external events and forces that cause exceptions to your business to occur? Can your people, your processes, and your technologies adapt within minutes and hours to update, and perhaps even create new necessary business processes?

In other words, are they proactively built to execute during times of change, uncertainty, and exception? Or do they solely react?

Do you want your organization to be an Exception-Tolerant Organization?

For more on the Exception-Tolerant Organization, please see this post.

Letting Go Of The Past

2009-05-05T18:37:00.003-04:00

A president of a technology organization has been very successful in satisfying a rather narrow vertical in a niche market. Under his guidance, a custom-crafted data warehouse and reporting engine developed over three years has been successfully deployed to his highest profile clients. This reporting engine was the result of a decade of this president's experience and development in this vertical.

The president, seizing on a new but potentially lucrative revenue stream, now wants to apply this data warehouse and reporting engine to a new domain, but one using a new report query methodology with frequent use of highly cross-tabulated data. The president brings in an experienced professional outside the technology team to lead the construction of software to support this new report query methodology.

After a review of the problem domain and the current data warehouse architecture, the team lead demonstrates that the current architecture will not store the data effectively, or quickly execute the queries in the new lucrative domain. The new team lead reports on the expected size and structure of data, and a potential architecture to support storing and executing the new report queries.

The president, disturbed by the team lead's negativity towards the older engine and data model, declares that this is not what he wants. The president tells the team lead to take the current engine and "fix it, make it better, but we can't redo it otherwise we're deviating from our platform. I don't want two platforms. We spent three years building this platform and we must use it."

The team lead, seeing the incompatibility of the current data model, asserts that a new data model and reporting query engine would need to be constructed, and that a new architecture could be backwards-compatible with the reporting queries from the president's current niche market. The team lead provides a working engine and database to demonstrate the new architecture's viability, integration with features of the current platform, and ease of construction to satisfy this new domain.

The president, after conferring with the older members of the team, is more disappointed than ever. But the other members do not have a strong alternative to the new team lead's solution. Not being technical but always willing to contribute technically, the president makes a few technical short-cut style suggestions. One suggestion is plausible to the new team lead, but the others have no connection to the new reporting query engine requirements.

A few of the technical team members take a look at the team lead's work and begin to agree with the team lead. But the president still does not come to an agreement with the team lead's assessment. Soon after, the team lead is off the project, while the president continues to search for a solution.

Should the president expect a custom data warehouse that took three years to construct, and that was fully paid for by the company, to be usable towards every revenue stream the president wishes to tap? Or does the president need to let this go and move forward?

Should the team lead reference the technical knowledge and experience accrued over time to make an assessment? Or, because of the new domain, should the team lead let this go and move forward?

Who is right in this situation? The president? The team lead? Keep in mind that what is most wrong with this situation is that the lucrative revenue stream remains untapped.

It can be difficult for us to let go of our past ideas and our creations in order to move forward, but in some cases this is actually what is needed to make the best of our present state and lead us to our future successes. If faced with a similar decision, do you think you could let go?

Publicity and Heroism in the Workplace

2009-05-05T17:19:00.007-04:00

Usually it feels pretty good to be recognized in the workplace or in your industry's community circles for your achievements, milestones arrived at, or just for a "job well done". You may also have had a chance to be lauded as a "hero" for landing that big account, completing that project on time and under budget, or working 36 hours straight to restore your organization's data warehouse up-to-date after a major hardware meltdown.

But have you noticed how the heroes who, say, weather us through a crisis sometimes receive more applause and "atta-boy"s than the heroes who, say, maintain steady but unchanging profits for years? Because of our human nature, we tend to be more attracted to the highs and lows of drama, rather than a seldom-changing sameness, even if that sameness is a positive and profitable one.

To land a major client, one organization had to close the deal and on-board the client within a very contracted time frame. A few principals involved were working 7-day weeks around the clock to the tune of 100 hours a week, while driving their teams to produce quickly for the client. At one point the client became very disturbed by a perceived lack of progress made by the organization in closing the deal. Shortly after the client made their feelings known to the organization, one of the principals mentioned to the client how he had been up all night working on a particular issue with the deal.

While that issue had not been completely resolved, the client was so impressed with the display of effort that they relaxed their expectations enough to accept the organization's progress, and became more receptive to future scheduling adjustments. Unfortunately, the client had not known about the 7-day weeks and 100-hour weeks spent previously. And even if they did, that knowledge may not have impressed them more than the image of one person toiling through the night solely for them. This is a much more dramatic picture indeed.

Some of us may need to work through the night from time to time to satisfy our organizations or our clients. Some of us in certain lines of work can easily work these hours or long shifts in a "business as usual" capacity. In either case, these shows of effort can easily be unrecognized, or worse, taken for granted if they are repeated too consistently. While being lauded as a hero shouldn't be the ultimate goal, make sure you are visible and your quality hard work is recognized.

Turning Cost Centers Into Cost Savers

2009-03-20T11:24:00.006-04:00

With almost 15 years of experience in the financial industry, and hedge funds in particular, I have held responsibility for not only enabling my organizations to use the best information available to make effective investing decisions and earn money, but also to effectively KEEP as much of the money earned as possible. I held this responsibility not as a trader or a front-line deal maker, but by working for and uniting two of the largest cost centers of these organizations - Operations and IT.

To be sure, any organization's Operations and IT groups are cost centers, especially when considered separately on their own. They exist as internal machines of the business, providing:

- the automation of workloads
- the storage of current, transient, and historical information
- the bookkeeping and checks and balances
- warehouses of business knowledge
- communication conduits to the front lines of the organization
- suggestive voices for organizational improvement and advancement

Put simply, Technology procurement and development costs money. Staffing and supporting Operations costs money. But now consider these other cost centers:

- fees on money held away as collateral for investments that have already matured, expired, or otherwise unwound
- time and effort repairing transactions and bookkeeping entries incorrect by factors of tens, hundreds, or thousands - discovered, validated and verified only well after their transaction dates have passed
- repetitive outbound money transfers now unnecessary due to changing market or exceptional conditions
- minutes and hours spent daily modifying business processes to work around technology limitations, because the technology in place is the only option offered to the business
- minutes and hours spent daily installing technology to keep pace with the cacophony of uncoordinated and seldom-related business process improvement requests
- unrecognized internal or external business events not brought to a principal's attention in a timely manner

These cost centers truly translate into money lost, not spent. Technology alone cannot automate and execute all of the business decisions required to reverse the direction of cost spent. Nor can Operations alone leverage enough manpower to execute and reverse the direction of cost spent in the necessary transactional time frames of seconds, minutes, and hours. If your organization can truly acknowledge the above as real cost centers threatening the bottom line, and acknowledge that IT and Operations separately cannot represent a silver-bullet answer, then your organization can recognize that a unified cohesive effort is necessary to reduce or eliminate these cost centers.

Now take notice of the last cost center mentioned above. Unrecognized events, being that they are unrecognized, do not have a workflow built into the technology to resolve them, nor are there any accruals previously posted on the books and records to account for them. Yet a poorly-priced security or trade, a trading partner's sudden unavailability to participate in a supply chain, or an incorrectly-prioritized customer order, could easily skew an organization's valuation or daily health snapshot into a hazard zone.

These events are the ones most sharply reacted to or chased after post-occurrence, often affecting not only the organization's capability to handle these scenarios, but causing a slowdown or loss in quality of the organization's regular business. If you are thinking that these events should be recognized rather than unrecognized, then you have taken the first step towards addressing the issue. The second step would be the desire to recognize these events and exceptions as soon as they enter into your business processes.

This is why I stress the need for organizations to become Exception-Tolerant, and build exception-based workflows into their business processes so that there IS a route for these exceptions to travel and begin to be handled timely. This can only be done through a united cohesive effort between Operations and IT, and is one of the best forms of internal risk management you could ever exercise.

So, can you unite your organization's Operations and IT cost centers into a more cohesive cost saver? Can you help your organization KEEP as much of the money earned as possible?

Communities Are A New Leadership Currency

2009-03-10T20:39:00.001-04:00

I recently spoke with a member of one of my communities who recently lost employment, and is temporarily renting her house and relocating a short distance away while she conducts her job search. I lent a sympathetic ear and words of understanding when she told me her story, but I also reminded her that she was still part of our community, and her value in our community did not change just because her employment or housing status did. In fact, because she has been so proactive in responding to the recent changes in her life, she may have planted a seed of community with her new tenant, one that may prove to be very valuable to both in the future.

Creating and sustaining a community can be one of the greatest challenges we face during rough times. People often feel disconnected when they experience both large changes (employment status, income, housing, family) and small changes (the closing of a favorite restaurant, the turning of a calendar page, or even the weather). Reminding people that they can be, and are, part of an entity that accomplishes more and increases in value when the entity's members are connected - this is the essence of community.

As leaders, we step forward to create and sustain these communities. We understand that our communities are a viable currency for investing in our ideas, and earning success for all involved. As such, we must continue to remind others that we are part of something that can accomplish more when we are connected. We must make clear that those involved in the community are investing in a currency whose value rises rapidly the moment that they step forward to become involved. No other investment market can provide such an immediate rate of return.

Whether your community is in your family, in your place of business, or a non-profit in your community (all three in my case), remember to remind others that they can and do belong in your community. Be the leader that invests in and promotes the currency of community, and reap the near-term rewards now while understanding that the long-term rewards will be even richer.

Resolving our Top Priorities

2009-02-18T12:42:00.005-05:00

At one point in my career I became champion for one of the most critical projects for an organization - one whose previous lack of focus on completion had already caused harm (including physical damage) to the organization twice in two years. As such, this critical project had been labeled "top priority" for this organization.

As champion, I had been dissatisfied with the lack of management focus on this top priority project, and brought this to the organization's attention. I was given a stern reminder by management that this goal was one of five or six top priority projects, and that the resources and focus necessary to complete this goal would be utilized across all five or six projects as they were available. And in the months that followed, this project did not experience the appropriate increase in focus as it continued to compete with the other projects for attention.

In your organization, is there an actual "top" to the list of priorities, or is it more of a raised plateau of several priorities all seeking to be fed? Can any of the following priorities for an organization be considered absolutely Priority One:

- Generating new leads
- Delivering increased product
- Bringing the next technological innovation to the marketplace
- Replacing aging infrastructure with current or next-generation systems
- Reorganizing to maintain competitive advantage
- Generating enough revenue to keep the lights on

Certainly every organization needs to do all of the above, and needs to do them well in order to thrive in the marketplace. It seems impossible for many organizations to focus on one of these priorities over some of the others, but some careful examination may yield more clarity in addressing priority:

- Do these priorities compete with each other?
- Do they complement each other?
- Does the completion of objectives of one priority facilitate the completion of objectives in another priority?
- Will our resources be able to address one or more of our priorities while covering business-as-usual responsibilities?

These may be simple questions that require intensive analysis to answer, but it is worth re-reading the questions often when we start to lose ourselves in tools, charts, and numbers. It is also worth reminding ourselves that allocating and juggling six top priorities really amounts to seven in number - one priority is the actual juggling effort that takes place while trying to manage the other six priorities.

Another consideration is where in the organization these priorities need to be addressed. There are areas in an organization where priorities and responsibilities must be partitioned in parallel, and there are areas that must be focused on a top priority objective. The management of the organization above had not quite figured out the optimal locations of partition and focus.

As many of my readers know, this is not as simple as a top-down partitioning and arrangement of responsibilities. An organization's current structure and its culture can greatly help or greatly hamper this analysis. You see evidence of this when organizations announce numerous reorganizations and restructures within the span of two or three years. They are still seeking the proper structure of partition and focus to complete top priority objectives. Or worse, they are seeking the proper structure that will help them define their top priority objectives.

If your organization is experiencing uncertainty with juggling or establishing an order for top priorities, try taking on at most TWO top priority objectives at once, one primary and one secondary. This way your organization will have TWO objectives completed rather than five or six that remain suspended in a perpetual juggle-state. In today's marketplace, juggling priorities is not an excuse for lack of completion of any one or two top priority objectives.

When Numbers Don't Tie

2009-02-18T11:47:00.005-05:00

One of the great sages I worked with for many years was fond of saying, "If you're not in control, you're out of control." I still have yet to find an acceptable shade of gray in this space. The space under consideration here is one of the most necessary, most costly, and most ill-executed processes in all of human finance - reconciliation.

As a definition, reconciliation is the process of verifying the equality of two values of data - each owned by a separate party - and performing the necessary actions to bring those values to equality.

More informally, in our work and our lives we are responsible for performing reconciliation in many disciplines:

- Verifying the same numbers produced on two reports with different purposes, but sourced from the same data
- Aligning debits and credits on a general ledger
- Confirming the current values of our investment portfolios
- Balancing the checkbook
- Ensuring that if one child has 10 pieces of candy, the other children get 10 pieces of candy

We willingly perform reconciliation because our organizations depend on it for their effective operation, and because as humans we have a constant craving for order and control over our lives.

Despite this, we constantly hear about organizations underestimating their own customer bases, misstating profits and losses, missing earnings reports, and going under due to incorrectly tracked assets and liabilities. If we are so naturally inclined towards reconciliation and order, then why are we so bad at it?

The three stages of reconciliation below may shed some light on an answer to this question:

- Avoidance of diligent and periodic reconciliation
- Reconciliation with the appearance of order - number and value matching without investigating underlying causes
- Reconciliation with the explanation of order - values and their differences are explained

Why would we avoid such a process that we naturally incline towards? We avoid it because it tells a truth of equality - one made of order - but not one that always puts ourselves or our organizations in the best light. And we avoid it because it requires a daily disciplined diligence that we feel we don't always have room for in our lives.

The appearance of order is our most common product of reconciliation, as the psychological payoff is immediate. Numbers and values that look the same on paper must be for the same purpose, we tell ourselves. Children feel they are equals when all have the same number of candies. An organization's performance numbers look better when certain values are stripped, weighted, or ignored. As we become psychologically satisfied, we stop searching deeper for the truth of equality as we have reached a truth of satisfaction which is "good enough".

With the explanation of order there is an explanation for the difference in mismatching values, the expected actions needed to resolve the mismatches, and an expected date of resolution. From personal experience, I know just how much hard work this can entail to assemble this explanation, and follow up and make sure the mismatches are resolved. And although we humans do crave order, our brains are more satisfied making numbers match together in our minds, versus seeking out the true purposes of the values and the reasons for the mismatches.

The explanation of order is the hard work that puts us in control, lets us make the most effective decisions for our organizations, and prevents damaging assumptions from taking hold. But when numbers don't tie, we fall out of control. Organizations falter, humans miss their goals and satisfaction targets, and economies collapse.

So - are you in control?

Lasting Improvements in Technology

2009-02-04T07:59:00.006-05:00

One of the most exciting benefits of uniting Business and IT is bringing true and lasting improvement to an organization's technology and and business processes. The promise of a streamlined and state-of-the-art business, quickly delivered and scalable beyond today's needs, is what we leaders strive to fulfill for our organizations.

Especially when beginning any new technology venture for an organization - whether it be a brand new organization-wide system, a major system-wide infrastructure upgrade, or simply a reclamation of broken and decayed business processes via a series of system sunsets - there is a certain electric buzz, a great sense of optimism, and a desire to improve quickly. Our organizations want to see immediate improvements and positive ROI within 6 to 18 months. And to be sure, it is easy to make marked improvements in systems and processes that are bloated or just plain awful.

But for leaders who are uniting business and IT - especially CIOs, CTOs, and COOs - we always have in our mind that the real challenge and achievement is sustaining these improvements over a three to five year span. This often requires us to shepherd change and improvement through perhaps one or more paradigm shifts in technology thinking and implementation. We acknowledge the fact of life that technology will come and go, and that keeping pace with the advances in technology can provide a competitive edge. We do not just introduce a new technology, expect it to take hold immediately with zero consequences, and wait for the right "gotcha" moment to blame the technology for not sustaining improvement.

As an example, take Service-Oriented Architecture (SOA) - perhaps one of the largest paradigm shifts and technology buzzwords over the past 20 years. For the vast majority of organizations, today's tools make SOA exciting, approachable, and quite doable. It is true that you can implement quickly and within 18 months see measurable improvement in your business processes. But, as with most improvement initiatives and technology paradigms, there is much more to consider.

Bringing SOA into an organization can be exciting, but aside from the technology ramifications, the effect on organizational culture is tremendous. Has your organization considered and provided acceptable answers to these questions:

- Does your organization expect services to be publicly available "at their fingertips"?
- Is your organization acknowledging and accepting the contractual terms of each service, including the data formats and valid data values that need to be marshaled across divisions?
- Is your organization willing to monitor and measure the usage and performance of these services?
- Can your organization measure the capacity for adaptability and extension of these services?
- Does your organization expect to be able to construct on-the-fly "composite products" based on using your services as building blocks? And what constitutes acceptable performance and turnaround speed?
- Will the new technology and service-orientation match the goals and values of your company?

Considering these questions, ironing them out to create sufficient answers for your organization, and overhauling your organization's technology to represent your organization's values towards SOA, will certainly take longer than you may expect or plan for. You will need to let your technology breathe and work in your environment for a while as you streamline your answers to the above questions. But creating those "composite products" based on the service-oriented building blocks will come when your service-oriented technology can measure up to the terms of service you set forth.

Much like the old advice to live in a new house and get acclimated to it before fully furnishing every room, so must we get acclimated to the new technologies and paradigms that we bring to our organizations before improving on them. We must continually ask ourselves the above questions, and evaluate the technology improvements we make - both the quick ones, and the ones made over time. Sustain improvements over a three to five year period, and your organization will have hit the jackpot.

Business Acclimation to New Technology

2009-01-14T12:08:00.005-05:00

Preparing for the arrival of a new system or technology can be an exciting time. The anticipated rewards of saving your organization time and effort, coupled with new reporting and business insight capabilities, all raise the prospects of successfully meeting the challenges ahead and handling the unanticipated exceptions that may occur along the way.

It is easy and natural to anticipate these benefits. But do we always anticipate the design and effort required by the business to accept a new technology into the business process? In other words, do we anticipate the necessary acclimation required by the business to take ownership of the new technology or system?

New technologies and systems are proven successful when the business acclimates to the new technology by successfully integrating the technology into their business process to provide the anticipated rewards. You know when this may not be happening when you start hearing about workarounds. When business principals need to institute workarounds in their process just to satisfy a particular set of system features, the business process itself can become warped and burdened with additional confusion and expended effort, which can cost the organization greatly. This trends a reversal in all of those great benefits and rewards the technology should be delivering.

So how can we avoid these reversal-of-fortune situations? We need to consider the matter from both the technology and business point of view.

On the technology side, we need to remind ourselves that our technology solutions, particularly custom and niche systems, should be designed and tested alongside the business model. The technology is not an entity unto itself but supports an important function of the business. Our technology solutions should also be capable of extension, to facilitate adaptation to the changing conditions in business processes. These two points can and should be continually tested and validated throughout the design and development process. This testing does not need to wait until a full system exists, as it is better to correct or dispel any incorrect assumptions early on in the life cycle.

On the business side, we need to remind ourselves to consider how the new technology will integrate into our business process. We need to ask ourselves these questions:

- Will the new technology be a fit for the capabilities of our organization and its people?
- Can we realistically analyze the weaknesses in our own business processes, and look to see how and where technology can assist?
- Are we able to pre-consider and design up-front any workarounds that may be necessary to work with the technology, but still realize the full benefit?
- Can we keep pace with the education, testing, parallel processing, and gradual rollout necessary to take ownership of this new technology? Or are we seeking a solution to arrive on our desks first before taking any further action?

Business acclimation to new technology deserves some serious consideration, and should be factored into any SDLC and project plans. If we do not, then we only increase the risk of our business processes ending up as slaves to our technology, rather than having the technology out there working for us where it belongs.

Agile Success During Challenging Times

2009-01-13T15:24:00.005-05:00

2009 is shaping up to be a challenging year for many organizations. Their people are being asked to do more with less, or do more just to survive in the marketplace. But there is more to being able to survive than just "doing more".

Challenging times require us to expect risks to materialize, be systematically ready to meet exceptions head-on, and advance our adaptability. This is where being agile becomes critically important for those organizations looking to rise ahead in 2009. And yes, even in challenging years, it is possible to succeed.

Here are two Agile success stories from my own experience with challenging times:

Problem: With a rapidly failing data communication pipeline, and a 1/3 reduction in technology headcount, an organization under tight deadlines to restructure its business needed a replacement for the pipeline quickly. With such a sharp reduction in technologists, the replacement pipeline had to exhibit a low-maintenance footprint while making it easy for the remaining technologists to extend its capabilities under the organization's new business structure.

Agile Solution: By including all the technology team members from the start, everyone was clear on what was at stake, and generally what each member's contribution would be. The team analyzed and designed the extensible solution together, proving it first on whiteboard, then taking adaptable technology to construct the first working version in one day - the total time representing a one-week iteration.

Frequent iterations were then used to construct and deploy vital features of the pipeline. From the time that the first version was working, the technologists assigned themselves to the tasks and pipeline features to complete. By meeting daily, and cooperating with the project leader and their project teammates, they "pulled" down the tasks themselves, rather than having tasks "pushed" or forced onto them. This translated into both faster task completion and higher quality of pipeline features.

The extensible architecture allowed the technologists to deploy the replacement pipeline early and incrementally, but swiftly bring the pipeline's features live at the earliest possible moment. The new solution represented a lower server deployment footprint than the older pipeline. And the servers hosting the failing pipeline (targets for consolidation themselves) were able to be decommissioned much sooner than expected, providing an additional much-needed cost savings to the organization.

Problem: An organization has an imminent opportunity to expand its business. But, its daily processing includes too much manual interference to correct data transmission errors. Business principals are often overworked chasing after data problems and manually translating data from one system to the next. Technologists are too often paged overnight to correct data transmission problems, representing a higher cost to the business when they are not available during the business day to correct the next day's problems. The organization's processing capability is unable to keep up with the new business.

Agile Solution: With only a few weeks to spare, all technology and business team members were included at the start, understanding that an intermediate technology solution is needed to sharply reduce the data transmission errors while alleviating the burden on the technologists to make repairs. User stories were created to detail the desired goals of the business, while demonstrating where the technology could assist. The stories were translated into realistically completable tasks, the effort to complete these stories was estimated by the team using "story points", and the stories were prioritized by the team and assigned into weekly iterations. While a release burndown chart driven from the story points was used to display and chart progress to senior management, the user stories were the focal point of the team's understanding of the challenges faced and the scope of the solution.

This new solution, in addition to reducing the amount of data errors and overnight pages, allowed the business principals to be self-sufficient in repairing the remaining data errors. Any new errors identified by the business could be repaired by the system, thanks to the use of user stories as a model for providing a solution to future data errors.

Leading the Way In Technology and Business For 2009

2009-01-05T14:54:00.004-05:00

2008 notwithstanding, this year is shaping up to be one that will truly change the playing field of business; the one that will introduce new competitors to the landscape while retiring others. Perhaps, like me, you have begun to ask - who will lead the way?

Well, the one answer that I propose that you consider is YOU! When you examine the usage of your technology to run your business, ask yourself if you are leading the way:

- When you must examine your daily sales or P&L reports at 9 pm, only because "they cannot possibly be produced any earlier", are you leading the way?

- When your intranet web application needs a twice-daily reboot during the most critical portion of the business day, adding an extra hour or more to your business principals' workday, are you leading the way?

- You've approved the $350k middleware solution and the matching salary overhead to produce a critical automated data pipeline. Yet six months later, your technologists are taking turns arriving early at 6 am to manually start up the first few stages of the pipeline, and once or twice a week this is inevitably delayed. In addition, your technologists are heroically correcting data and processing errors in-flight several times a week. Are you leading the way?

- When, after a long day's work, you are logging into your organization's systems every night at 3 am, just to watch the overnight jobs run and "make sure" that nothing goes wrong, are you leading the way?

- When a major data stream is unavailable during a critical processing period, and no alternative streams or pipelines exist, your business process is delayed indefinitely. During this delay, are you leading the way?

Like most of you, these are just a few of the many issues that I have had hands-on experience addressing and resolving for the benefit of our businesses. Perhaps you and I also have produced some issues of our own that needed a different angle of consideration, a different path to success. Resolving these issues, and many more like them, is what we leaders must strive for.

So, for 2009, will the way you use technology give you the confidence to run your business well, handle the exceptions that arise, and allow yourself to sleep? Will your technology let you and your business lead the way?

The Exception-Tolerant Organization - Roundup

2009-01-05T14:41:00.003-05:00

The series of posts on the Exception-Tolerant Organization (ETO) can be found here:

- Introduction
- Part 1
- Part 2
- Part 3
- Part 4
- Part 5

I look forward to expanding on this topic and other critical issues uniting business and technology in 2009!

The Exception-Tolerant Organization - Part 5

2008-12-31T11:04:00.001-05:00

As explained in my introductory post on the Exception-Tolerant Organization, ETOs do not tolerate waste, stifling of innovation, or inflexibility. These are the corrosive agents that prevent an organization from smoothly handling exceptions, maintaining a competitive edge, and operating effectively.

When I was at IBM Research I knew of a research Fellow who would monitor the keystrokes made by his administrative assistants while they were typing, and would spend quite a bit of time with them working on utilizing the fewest keystrokes possible. This is intolerance of waste taken to the extreme, where a few burning trees are saved while sacrificing the forest. Although it is quite easy to disdain waste made at this low level, this is not the kind of intolerance we are discussing here.

While the canonical definition of waste is anything that does not add value, what exactly constitutes waste for the Exception-Tolerant Organization? As previous posts have mentioned, exceptions happen to organizations, to customers, and to people every single day. Those organizations that cannot handle the exceptions and improve from them will fight a constant perception of lower value in the eyes of their customers.

For those who understand the benefits of mapping a value stream, waste would be anything that slows the velocity of movement through the value stream. The inability to swiftly handle exceptions can bring this velocity down to near zero. Being Exception-Tolerant can keep the value stream moving at the pace of innovation.

Waste for the ETO, then, is the set of roadblocks to handling exceptions: inflexibility combined with the stifling of innovation.

Inflexibility is tough to exhibit while being Exception-Tolerant, but is even tougher to recognize in an Exception-Intolerant organization. After all, there are certainly industries and products where strict and rigid standards must be constantly and consistently adhered to (watch-making, food preparation, chip manufacturing, aerospace), but these should not be mistaken for inflexibility. Chip manufacturers, despite adhering to the use of 30+ year old computer code, have been able to find avenues of flexibility in many ways over the past few years - from lower-voltage conduits to hyper-threading to multi-core pipelines.

Stifling of innovation is perhaps the touchiest subject when it comes to organizations who may be looking to become Exception-Tolerant. The urge to suppress innovation is strong in risk-averse environments, and is often exercised in such forms as:

- the boss consistently saying "No"
- a departmental control group demanding that a potential innovative division look and operate the exact same way as the existing divisions
- new ideas whose implementations are unduly laden with process, direct-to-archive documentation, or extreme executive input

The stifling of innovation is often a by-product of culture, and the effects may not be felt in world markets until long after the key culture-makers have moved on. Strong cultures that stifle innovation are not often discovered by the outside until the effect in the marketplace becomes obvious. ETOs, even ones with strict standards, have a tough time saying "No". Inflexible organizations find it all too easy to say "No" and close doors on new ideas and customer needs by stifling innovation.

But with all the good work that we as people do, and all the work that we endeavor to do, how do we let ourselves get into a mode of inflexibility and resistance to innovation? The hard truth here is that we most often become inflexible and stifle innovation when we put self-interests above working together as a team. There is good reason that this struggle is often labeled as the war within.

But the other side of this hard truth is that ETOs are given credit by their customers for handling the exceptions and increasing the overall value proposition. And when credit is given in this fashion, ETOs give their people, who have worked together as a team, every opportunity to take the credit and reap the rewards - thus making team achievement in the best self-interest.

Valuating Technology System Delivery

2008-12-19T11:54:00.006-05:00

A well-worn but still prevailing theory of system delivery states that a system can be delivered according to three main factors:

- the system is of high quality and functionality (a "good" system)
- the system runs speedily under all conditions and usage loads (a "fast" system)
- the system can be built and delivered inexpensively (a "cheap" system)

The conventional wisdom is that a system can be delivered possessing AT MOST two of the three above factors. In other words:

- a good and fast system cannot be delivered cheaply
- a good and cheap system will not run speedily
- a fast and cheap system will not be a good system

You may or may not hold this view yourself, but many still do. Of course, it is quite possible (and rather beneficial) to have all three factors represented positively in a system delivery. But you need to look at the entire lifecycle of a system to understand this, not just the planning and construction stages.

Many under-weigh, or ignore completely, the usage and maintenance portions of a system's lifecycle when evaluating TCO and ROI. If the system's features, functionality, and construction are underrepresented before the system is delivered, higher costs will be made apparent later in the lifecycle:

- the system's users will invent workarounds to their normal business processing, just to accommodate the system's lack of performance or mis-matched view of the world. This usually leads to weaker controls and gaps in business processing, which leads to anywhere from higher operating costs to lost revenue.

- the system performs poorly or contains only a few compelling features, but just barely enough to be useful. While there could be no justifiable loss in cost, the cost to keep-alive the system plus the cost to improve and re-architect the system could easily be more than double the initial funds promised. Building a more desirable and well-performing system might have cost more up front, but still could have been less than the funds needed later for repairs.

- the system performs so poorly, or contains such a lack of compelling features, that it will not be used at all. This represents a loss equal to the cost of construction of the system, plus the difference in current operating costs that may have been saved, plus the cost of lost opportunity to improve and be competitive.

So how do you deliver a system that is good, fast, and cheap? Stating the system's costs and its benefits over the ENTIRE system lifecycle, both with equal precision, will help you arrive at acceptable definitions for "good", "fast", and "cheap" for your organization. But without the equality in precision, someone is bound to be disappointed upon delivery of the system.

So which lifecycle phases and cost factors are you accounting for in your system delivery analysis? Do you feel that you have all the bases covered? And how is the precision measured?

Act Like An Owner

2008-12-19T11:39:00.005-05:00

Does your organization ask you to act, and think, like an owner? Does your organization ask this of you when you come aboard?

What would an Owner do in your organization? Would an Owner carry a vision? Innovate? Seek improvement and new opportunities?

Would an Owner cut corners? Cut costs? Maintain the status quo?

Would only an Owner understand the key drivers to the business? Or could anyone else in the organization achieve such an understanding?

Does your organization educate and allow you to understand the key drivers to its business?

Does your organization allow you to cut corners and costs? To maintain the status quo?

Does your organization allow you to carry a vision? Innovate? Seek improvement and new opportunities?

Your organization may ask you to act like an owner - but does it allow it?

The Exception-Tolerant Organization - Part 4

2008-12-19T10:59:00.005-05:00

As explained in my introductory post on the Exception-Tolerant Organization, ETOs practice daily Risk Management. Another concept that sounds quite simple, but organizations find it difficult to sustain due to these key factors:

- lack of inertia and momentum
- lack of systematized and/or automated assistance
- key-man risk and blame

Lack of inertia and momentum comes from not instilling review activities into the organization's daily operations. Just asking these fundamental questions on a daily basis goes a long way towards an effective review process:

- What did I accomplish yesterday?
- What am I working on today?
- What obstacles or problems am I facing?
- How confident am I that the current goals will be accomplished on-time?

For many organizations that rely on reviewing large amounts of performance or other time-sensitive data, having a systematized and automated collation and presentation of this data is key to establishing a daily momentum. The systems and processes supporting them should have the appropriate fail-safes and redundancies to handle exceptional processing cases so that timely delivery (and thus Risk Management momentum) can be maintained.

Automated assistance is also key for the human side as well. In reviewing an organization's performance or exception conditions, leaning on automation can clear our heads of the mundane and manual steps, and allows us to focus on the exception conditions. Plus, what Director of Risk Management wants to arrive at work at 7 am just to push a button, or wait for reports 1 through 10 to finish running and printing before tackling the issues of the day?

Being a Director of Risk Management is a tough proposition to satisfy for an organization. Not only must you have volumes of data and information at your disposal, you must have the prescience to understand what is going to happen seconds from now in both your own building and halfway around the world. A Risk Management Director could be hailed as the heroic steward of the ship that avoids the icebergs of a competitive landscape, or could easily be the goat when the ship is steered right when perhaps it should have turned left.

For an organization, it is easy to both funnel singular responsibility and cast blame on one person when things blow up. But why do this, when after the blame subsides, the organization is still in an unfavorable situation when a risk materializes? Risk Management is one of those cross-cutting activities that the entire organization can practice effectively on a daily basis via continuous review and improvement. Allow your Risk Management Directors to get the support of the entire organization, and the Director will support the viability and competitive health of the organization in return.

The Exception-Tolerant Organization - Part 3

2008-11-15T07:56:00.006-05:00

As explained in my introductory post on the Exception-Tolerant Organization, ETOs emphasize their strengths and compensate for weaknesses by working together and communicating openly. If the concept sounds simple, that's because it is simple. But with all of the advanced ways, means, and tools we have at our disposal to collaborate and communicate openly, we still find in today's world places and situations where these fundamentals are simply not done.

Working together involves several cultural practices within an organization:

- Total team involvement from the start
- Proactively seeking the improvement of the organization
- Staying open to new ideas and possibilities
- Shared goals without harmful personal agendas

The first point is easier done than said, but the other three involve a resistance factor to change within our organizations. ETOs have the cultural grounding to foster and promote all four points above. As discussed in Part 2, ETOs systematically implement the communication pathways and processes to support these points.

But as is often the case in life, the greater challenge in overcoming obstacles can come from within ourselves, especially on the last point above. We don't always realize that we are more in competition with ourselves than we are at odds with others, and many times we are better served improving ourselves and overcoming our own shortcomings. Instead, we often put up walls where requirements and miracle solutions are volleyed back and forth, neither ever really satisfying the concerns or goals of the parties on both sides of the wall. But when we take down the walls and mprove ourselves, our best foot is then truly placed forward for the benefit of our organizations. Our strengths become the organization's strongest capabilities to be deployed across the greatest spectrum of benefit. And our weaknesses are compensated for by our continuous self-improvement, by identifying risks early, and especially by communicating openly.

Communicating openly, at its most basic level, involves face-to-face discussion, debate, and sometimes conflict - something that people can tend to avoid, in both their personal and professional lives. But for open communication to be effective, an environment needs to be created by the organization where intense debate and disagreement are tolerated, and conflicts can be satisfying to resolve. The organization should make it clear that it is okay to disagree and debate issues, but the result of each debate should still include a clear decision to move forward along a certain path of action.

As an exercise, have everyone in your organization begin to answer these questions out loud daily. Ideally, everyone related to a project or a core business of your organization should be in the same room (or on conference if necessary):

- What did I accomplish yesterday?
- What am I working on today?
- What obstacles or problems am I facing?
- How confident am I that the current goals will be accomplished on-time?

For the last question, use some kind of rating scale. Example: have each person rate their confidence from 1 to 5, with 5 being the most confident. Any answers below a 4 should be a cause for concern and those concerns should be addressed openly. The Agile practice called Scrum advocates the daily use of these questions.

Communicating openly also involves the appropriate use of communication tools. Communications involving urgency or time sensitivity should use direct methods: direct-line phone, internet, and video calls; direct text messages/pages; and of course face-to-face conversation. The use of email and instant messaging, while becoming increasingly mobile and location-independent, should not be relied on for urgent time-sensitive communication. These communication methods often have either multiple inboxes or streams/threads of communication occurring simultaneously, have lengthy queues of messages attached to them, or depend on having your communication device successfully "subscribe" to that message stream. The number of inboxes/threads and the size of the inbox queues are things that you cannot guarantee to be small enough so that your urgent message is received timely. Eliminate this frustration up front by identifying early a reachable line of communication to use for urgent matters.

Some very simple and fantastic exercises in working together and communicating openly (many taking 10 minutes or less to complete with a noisy room full of people) can be found here. While some of these are focused on Agile principles and practices, many of these deal with the core issues of communication and collaboration, and may help to expand your thinking. My thinking was certainly expanded after participating in some of the exercises. My thanks to Michael De La Maza for bringing these to my attention.

Challenging Our Assumptions

2008-11-10T10:39:00.004-05:00

At a recent party I sat with a technology team whose members were dejected from having their latest project terminated by their company. This team spoke fondly about their months of development, their early adoption of cloud computing methods and technologies, and even their conferences and consultations with members of NASA regarding the use of advanced technologies. They shook their heads and couldn't understand why the system didn't succeed.

This team had hailed the project as the next great data transmission hub for the team's company. They specified communication protocols and APIs, worked with the application developers to foster understanding, and even reviewed a few sample data streams to understand the problem space. The project seemed to have everything going for it. But during construction of this hub, the team made a fateful design assumption regarding the separation of data streams within communication channels.

This assumption was that data streams could be separated by a data pattern that would "never be seen" in the actual live data itself. The team was warned by the application developers and certain managers that the possibility of this data pattern showing up in live data was in fact likely. Still, the team moved forward with completion of the system, performed some successful testing with a thin time-slice of data transmissions over a period of several days, and then went live with the system.

Within three hours of the system going live, this data pattern delimiter showed up in several places in the live data. As a result, the system was delivering incomplete data and crossing data transmission streams. Processes that were dependent on this new data transmission hub had to be reverted back to their old transmission methods. Beyond changing the data pattern delimiter to something else that might "never be seen" in the actual live data, the team did not have an alternative solution to this problem. And thus a short time later, the project was terminated.

Unfortunately for this team, a fundamental design assumption was made early on that contradicted directly with the problem space that their solution would address. The lack of challenge, investigation, and thorough testing of this assumption sealed the project's fate. While we are often proud of our assumptions, we are made better when our assumptions are challenged and tested at the earliest possible opportunity.

Project and Technology Development Methodologies

2008-11-06T09:43:00.006-05:00

Rather than be the trillionth blogger writing on the subject of Agile, refactoring, Test-Driven-Development, domain-driven-design, and other practices and paradigms, I'll lay out some pragmatic principles to keep in mind when executing projects, no matter which development practices you adopt. In the rush to absorb the hottest trends, we should keep in mind the tried-and-true principles that still work:

Start with iterative and incremental. Project phases are well and good, but in order to complete a project successfully, the path to completion needs to be traversed. And yes, you must have an idea of your destination. But will you wait until all requirements are specified to the last detail before moving on to any architecture or design concerns? Will you have a design project phase that takes into account the current state but fails to connect with the changes in the world three months later when the design phase is completed?

If you break down your project phases into iterations, with a guaranteed feedback session at the end of each iteration, you will be much more likely to keep up with changing requirements and conditions. You will also be able to identify failing efforts sooner, before they cause damage later.

Start as soon as you can. One of the common reasons for project slippage is that some critical component or project dependency was not available earlier in the project cycle. Was it because the need for this component was not forseen? No, it was just not available at the appropriate time. One way to mitigate this is to start working on these components after just enough baseline requirements have been gathered. You may spend a little more up front to support this initial development, but it will cost you far more in the long run should you end up in an ill-timed slippage scenario. The ways it may cost you range from longer development cycles to mis-timed market entry to project personnel turnover. These are big-ticket costs.

Military leaders are trained to make decisions with 40% to 70% of the information necessary, and regularly provide feedback as more information is available. You can do the same on projects and be very effective.

Do your Risk Management. As stated so eloquently in the fantastic treatise on software project management Waltzing With Bears, "Risk Management is Project Management for adults." Listing and valuing project risks is something that can be done to 100% completion up front. But the great (and sometimes painfully realized) thing about Risk Management is that 100% completion is often not enough. Here is a great place to be iterative and incremental in providing feedback loops on the state of risks, mitigating circumstances, and changing requirements. If you build the iterations and feedback loops into your risk management on a project, the rest of your project practice will need to follow suit just to keep up.

You'll also be more inclined to tackle project deliverables that resolve the greatest risks first. The sooner these risks are resolved, the more accurately you can publish a date range for delivery.

Test early and continuously. Your project exists in some form from start to finish. It may start on paper, and live in hardware and software at the finish. But in whatever form it exists, it can be tested. As new requirements are gathered and formulated, test cases can be drafted and pitted against the project's assumptions. As new hardware is installed, its images and monitoring agents can be configured and proven. As new code is written, test cases can be written before or alongside the code.

Don't wait for a project to be 50% or 75% completed to start drafting up test cases and setting up a test facility. Automate much of your tests if you can, so that they can be run at least once a day. Automation is again a case of a little more effort up front, saving much more cost and headache later.

The Exception-Tolerant Organization - Part 2

2008-10-30T10:16:00.004-04:00

As explained in my introductory post on the Exception-Tolerant Organization, ETOs build the communication pathways, business processes, and technology features to handle exceptions systematically. Where the business processes and technology features are largely matters of construction, the essential communication pathways can often be the component most elusive to an organization.

To relate this to a recent business event: an organization was forming a new business venture, bringing mature and existing technologies and processes in house from one of their partners. In the suite of this venture's features, there was one particularly public-facing feature that was not even close to being on par with the rest. Very early on in the business venture, one principal surmised that this feature had the strong potential to sully the reputation of the organization, and told the other principals of his analysis and recommendations for a course of action. A few principals were sorely disappointed that this was brought to their attention so early in the business venture, as they felt that this "negative" analysis was not what was needed during the venture's "honeymoon" period.

About one year later, the other principals began to see the strongly negative customer reactions to this public-facing feature. When they approached the principal who originally gave his analysis, they said to him "You didn't tell me it was THAT bad." In this case, the communication pathways were cut off early in the venture, perhaps when they were needed the most. And when they were opened again a year later, it was done in a reactive fashion that does not lend itself towards a systematic way to handle exceptions.

So how can you create these communication pathways? You can begin an email thread, as the principal above did, but these threads either are ignored early, or become so long that the interest drops off quickly. You can appoint a single point of contact to receive and dispatch the exceptions, but that person ends up being a single choke point more often than not. Or you can set up a system purely to capture issues and exceptions for review, which relies on people willing to take the few necessary minutes to input their issues into the system. This system can provide an effective entry point for exceptions and issues, if your organization is culturally adaptable to putting an entry, approval, and management process in place. The organization above did go and implement such a system.

Whether this type of system is a cultural fit for your organization or not, a regularly-scheduled gathering of the principals solely for the purpose of reviewing exceptions would go a long way towards getting the effort off the ground. Your organization may need to lighten the "status meeting" load somewhat to make room for this type of gathering. But because of the regular schedule, you are that much closer to systematically handling your exceptions.

As stated above, the business processes and technology features are largely matters of construction. But where business processes are concerned, many organizations focus on constructing processes for project lifecycles, development lifecycles, change control, and administration. These can be helpful in measuring performance when they are not over-engineered, but they are all are intended to handle the "normal" course of business. This still leaves out the what-just-happened, where-do-we-go, and what-do-we-do when an exception does occur.

As a starting point, take the lead from technology support teams. Great technology support teams have an initial point of contact, an exception entry and tracking system, and "run books" that contain procedures written in detailed step-wise fashion documenting EXACTLY what to do when a particular exception occurs. When an exception occurs and is identified, the support team executes the procedures step for step. If there is an exception that they cannot identify, they still have a procedure for this case that may involve contacting someone with more knowledge of the systems.

Handling exceptions in this way leaves little guesswork as to how to initially react. For many exceptions, recovery is a matter of reacting safely and sanely first, and then following the steps. So for your organization's exception-handling process, write down in step-wise fashion what people should do when there is an emergency exception, a impactful exception, and a minor exception. Every detail, including which people/departments should be contacted, the appropriate time frames to wait for responses, and any system or documentation entries should be noted. As a bonus, when you are out of the office and someone is covering for you, they can cover for you as effectively as possible during times of exception by following the steps.

For those of you who dislike process and procedure, keep in mind that the exception procedures exist to assist you, not to burden you. Your brain-power is most needed for problem-solving during the exception period - not remembering to make entries in systems A, B, and C; and worse, not remembering to notify people critical to your business. Another point of assistance is rendered when you can collect data from your exception-handling system and analyze the types and frequencies of the exceptions that occur in your organization. This may lead to some business insights your organization may otherwise not have reached.

Technology features for handling exceptions will be covered in a later post, but it is sufficient to say for now that your technology features that handle exceptions should interface and operate just like the technology features that run the normal business.

2008 Fairfield/Westchester .NET Code Camp

2008-10-28T11:19:00.002-04:00

I will be presenting at the 2008 Fairfield/Westchester .NET Code Camp on Saturday November 8, 2008. The Code Camp is an all-day conference that allows allows professional developers and students the opportunity to hear from experts in the field on a variety of topics, from programming language tools to Web 2.0 development to the latest and greatest in Microsoft technologies. Several Microsoft MVPs, Evangelists, and some of my past colleagues will be presenting. The camp will be held at UCONN Stamford Campus in Stamford, CT, and you can get all the details here.

As part of the Web 2.0/Agile track, I will be leading a live interactive Test-Driven Development session, which will allow you to observe a test-driven approach to solving a real-world problem. I hope to see you there!

Does Our Technology Equate To Lies?

2008-10-17T09:32:00.006-04:00

I recently had a conversation with a CTO with experience heading large and global teams. His recent work had concentrated on installing SOA-based systems into his organizations. He brought a viewpoint of his to my attention that related custom software development to a lie. The lie that you tell yourself, he said, was that a custom or one-off module or block of code solves your business problem the way you want it to. You're lying to yourself because the problem wasn't solved in an configurable, and maintainable, and service-oriented way.

He went on to support this statement by relating a story about lining up the dates in a fiscal calendar of a system that did not lend itself easily to change. A custom solution working around the constraints of an existing system was needed to meet the demands of the business, and he was not quite satisfied that the solution had to be of a custom nature. In his view, he preferred the solution to be service-oriented and configurable.

While I understand the CTO's view towards a service-oriented and configurable architecture, I don't think that his lie is attached to the appropriate concepts. Service-oriented or not, you can effectively eliminate the lie he speaks of by managing the lifecycle of the customized solutions.

If your business is sufficiently pained by the problem where you need a customized solution implemented and deployed urgently, and the solution has been appropriately constructed and tested, then by all means deploy it. But if the custom solution is not the most optimal, configurable, or maintainable, then put an expiration date on it and schedule the time and resources to implement the optimal solution by the expiration date. This way you would provide urgently-needed relief of the pain your business is experiencing, while having an outlook toward the optimal future.

But it is crucial that the follow-up happens. The common occurrence, and the real fear here, is that once a solution is implemented and deployed, people move on to solving the next problem or working on the next great project without coming back to readdress that sub-optimal solution. This custom development often ends up being yet another buried non-catalogued nugget of logic.

In the CTO's anecdote above, the custom solution is necessary to work around the larger system's constraints. But what if this custom development was configurable, maintainable, and service-oriented from the start? It is still a separate custom component, one more component to be maintained in the catalog of assets. In maintaining a service-oriented architecture, having an up-to-date and discoverable catalog of components, the contracts they satisfy, and their development artifacts is key to performing effective maintenance. SOA implementations typically have more components than non-service solutions, not less. SOA implementations without these catalogs can quickly become burdensome and error-prone to maintain.

So I think that the real ways organizations lie about custom software development are:

- not assigning an expiration date to sub-optimal solutions, and not managing the transition process from sub-optimal to optimal

- not maintaining an effective catalog of solutions, contracts, and components

- expecting a silver bullet or all-inclusive solution to eliminate the need for custom development

- not actually solving the organization's problems because no custom (or market-leading) solution is considered to be the optimal solution for the business

Unlike the CTO's organization, I've seen organizations with very painful problems put off implementing solutions for years because the solution candidates don't fit into the "optimal" category, service-oriented or not. If the solutions are not considered to be the holy grail, then nothing will be implemented at all. And the business continues to limp along in pain without further technology assistance.

Wrapping up my conversation with the CTO, he was considering implementing one of the larger off-the-shelf tools that can effectively assist in service orientation. He left me with the impression that these solutions, their price tag, and their large deployment footprint offered him great comfort in removing the custom development lies from his organization. But alas, that is a lie for another day.

Invited To An Idea

2008-10-12T13:55:00.005-04:00

Once upon a time a company had an idea - an idea whose direction was generally contrary to the overall company's market. This company made their idea wildly successful, as the great sages of the company built systems and processes to effectively implement the company's idea. But the great sages became trapped by their systems, because they required so much of their hands-on manual effort and control to execute successfully.

Enter our hero. Early in our hero's career, a few great sages invited our hero to become part of this company's idea. They did this by inviting our hero into their office and explaining the reports they needed to systematize and automate their manual systems. The great sages also explained that having these reports in place would free them to continue implementing the company's idea.

The great sages took their time with our hero, explaining why the reports were important and badly needed, and how the reports fit into supporting the company's idea. They always took time to answer our hero's questions and concerns about the reports.

These reports solved certain problems with supporting the company's idea, and freed the great sages to pursue supporting the company's idea further. This led to building robust systems, and led to freedom for many to further implement the company's idea. Over time our hero became a great sage at the company, one who would be free to enlist others and further implement the company's idea.

But after the years of work successfully implementing the company's idea, our hero was still not free.

There were certain functions in the systems that required only our hero. Our hero had willingly executed these functions because our hero believed strongly in the company's idea. And when there were problems with the systems requiring corrective action, our hero was there to the rescue nearly ever single time.

Over the years our hero grew to be responsible for executing more than double the number of functions than was originally intended. The company's great sages became used to the excellent service of our hero, and cheered our hero on all the way. Our hero had been invited to become part of the company's idea, but instead our hero had unwittingly been self-installed as a key cog in the systems implementing the idea. Under this arrangement, our hero could not be free.

When our hero finally realized the situation, our hero took corrective action. Our hero systematized and automated greater and faster than ever before - freeing our hero, and many others, from having to execute the functions that our hero solely used to perform.

But by this time, the company hit some turbulent times, lost sight of its idea, and lost one-third of its people. The company was no longer interested in inviting people to become part of its idea. But people were still needed to handle exceptions and support the company's idea using the systems the great sages and our hero had put in place. And without these people, our hero could not be free.

Our hero realized that at this point the only way to achieve true freedom to pursue the company's idea was by freeing himself from the company. And so our hero, exhausted but thoroughly grateful for the experience, moved on from the company.

Has your organization invited you to become part of its idea? Have you become stuck in the execution of your organization's systems like our hero was? Can you see a way to systematize and automate to free yourself, before moving on becomes the only path to freedom?

The Exception-Tolerant Organization – Part 1

2008-10-06T13:56:00.007-04:00

As explained in my introductory post on the Exception-Tolerant Organization (ETO), ETO’s can embrace change and uncertainty while systematically executing their business. There are two keys here to making this a practicality:

- Being able to systematically execute the business

- Having an entry point in each business process for welcoming the change and uncertainty once an exception event occurs

First, ETO’s are able to systematically execute their business. There is a system for each business process that the ETO’s people follow to execute, manage, and report on their business. This is not as complicated as it sounds, as there are systems everywhere in business: accounts payable, software development, computer machine and image preparation, accounting. And when the ETO’s people understand that the systems exist to support the major ideas and goals of the organization, no system is considered too mundane to be ignored, improved, allowed to decay, or allowed to bloat in size. There are many books and references on the web related to understanding the importance of systems and business processes, so I will not expand further here.

If your organization is not systematically executing your business, but rather executing in an ad-hoc and undisciplined fashion, it can be difficult to embrace any changes or external events. Your organization is already dealing with so much noise and individual solutions to regular business issues ---that it will not be able to differentiate an exception event from a regular business event. Note that this can be an advantage when looking to create a system, in that your best ad-hoc process may work just as well for handling an exception event as it does for conducting your regular business. If you find your organization in this situation, use your best ad-hoc process as a starting point for implementing a system that can be executed repeatedly without fail.

Second, each one of an ETO’s systems and business processes has at least one entry point for addressing an exception or a change. Organizations need a way for someone to bring an event warranting change or representing uncertainty to the business’ attention. As an example, Toyota production workers are able to stop the line when they see a problem during the production process. Stopping the line is their entry point.

Entry points for processes that must be executed daily and on-time can be more difficult to see with the naked eye. As an example, an investment portfolio that must be valued on a daily basis - one or two issues with the price of an investment can make the portfolio's reported value wildly inaccurate, and become grossly misleading to a fund manager's investors. The system of valuating the portfolio must have an entry point where exceptions with prices can be raised, diagnosed, and handled. The identifying and handling of these exceptions is a systematic process itself, often assisted by robust technology. The entry point can be an automated review of the portfolio, followed by an exception reporting tool with a pricing exception report as a backup.

An entry point for an organization experiencing a problem with internally-developed software is a help desk department, which has rules and procedures around when it is available to take calls, and its expected turnaround time when responding to issues and exceptions. In other words, it is a system. Other organizations may have a developer, system administrator, DBA, infrastructure engineer, or manager as the entry point for problems. All of these technologists have different schedules and structures to their day, and can serve as an effective entry point - when they are available. Business principals may even feel more comfortable going to them directly, as they feel that the technologists are closer to the solutions than the help desk professionals.

This often ends up being more effective from time to time, but less systematic. Technologists are often steered away from their scheduled and time-sensitive work to handle exceptions, particularly after-hours and overnight. But here is a situation that calls out for leveraging a system so that effectiveness can be assured every single time the entry point is used. Being exception-tolerant allows us to handle these exceptions without negatively impacting regular business. This will be continued in Part 2.

Leadership During Downtime

2008-10-02T08:36:00.008-04:00

When I browsed to LinkedIn early this morning, this is what showed up on a web page entitled "Oops!":

Sorry, we can't display this page right now.

Something unexpected has gone wrong. Please wait a few seconds and try again by hitting the reload button.

We apologize for the inconvenience. An error report has been filed and our team is working on fixing the problem.

If you have any questions, please email us at customer_service@linkedin.com.

For many developers and business users of web applications, this is an all-too-familiar sight when a web site is experiencing problems. But does it need to be?

LinkedIn is no doubt a leader in on-line networking and community. But while there is a link to contact customer service via email, the web page is pretty much out of character with the rest of the web site: no ads, no links to its user community's services and sites, no information about LinkedIn itself - in other words, nothing useful. We might as well have received the standard error page from the browser.

In a period of downtime, LinkedIn is missing out on an opportunity to continue leading the way as a premier networking and community portal. Just a few links and paragraphs of text can make all the difference, so that during downtime LinkedIn would never be completely offline.

A Breakdown In System Testing

2008-10-01T22:53:00.007-04:00

The latest release of the middle-office system has gone live, but somehow the pricing analysis screen, the most important screen in the entire system, will not accept prices entered for equity swap positions. It is at the end of the trading day, and the traders are getting heatedly upset.

Ask the developers, who are newcomers to developing for this system, if they tested the screen, and they say "Yes, but we didn't modify anything on that screen, so we didn't test it fully." Ask the business analyst if he tested the system, and he says "Yes, but I didn't test that screen because the developers said they didn't modify anything on that screen, so I just entered a few prices as a litmus test and that was it." Ask the development manager what went wrong, and he says "Didn't anyone bother to test the system? If I go into the system and try to enter this price, it's clear to me that it doesn't work! Are you all blind?"

Did the developers modify the screen directly? No. Is the business analyst lazy? No. Is everyone in the development manager's group blind? No. But is this breakdown of testing a common occurrence in software development? Yes. (A change to a pricing validator component shared by multiple components of the system, including the pricing analysis screen, was the cause of this situation.) And is everyone feeling sore about it? Absolutely.

So what is to be done? In this particular environment there is no systematic procedure for testing. The development group is weeks or months away from being fully up-and-running with automated development and testing practices and facilities, if they can carve out the time away from their regular responsibilities. Other than the business analyst, there is no budget for a dedicated QA/testing group. Yet something must be put in place quickly so that a system with shared yet inter-connected components can be reliably tested without negatively affecting the business users upon release.

This is the perfect time for this group to begin a testing practice built upon a foundation of acceptance testing. Acceptance testing proves the real-world conditions that every feature and function of the system must satisfy correctly and repeatedly.

Acceptance tests represent the common point of understanding and agreement between the business users and the technologists responsible for a system. If the system can satisfy all these tests consistently, every time the tests are run, then any changes to components can be readily verified as not having a detrimental effect on the system. And since acceptance tests are satisfying real-world conditions, the business users are given some measure of the system's reliability before the system is released. *

It does take a bit of work to get started and enumerate the acceptance test cases. It also takes some work to get both the business users and IT developers and analysts to buy into the process and realize the benefits. But ask the traders above and their staff if it would be better to be frustrated by a malfunctioning system. But building the foundation takes less time than you may think. You can start with one simple spreadsheet listing the test cases, but the point is to start somewhere. The journey of 1000 miles begins with a single step.

Once you have this foundation, then your developers can branch out into Test-Driven-Development and other testing practices, and your business users can be more self-sufficient in setting up test cases. There are even open-source tools that can translate Excel files and "natural language" test cases into actionable code (FIT, for example). Imagine the situation where your business users can keep up with changing business conditions by submitting test cases in Excel on their own, without having to know XML or a cryptic language. To receive the most up-to-date feedback, automate the tests so that their execution is a convenience to be enjoyed by all, not a burdensome task to be carried out by a lone savior/scapegoat. You may even find your organization creating defect-free releases before too long.

And the next time the middle-office system is tested, the only things taking shots are the components, business processes, and assumptions made about the features and functions - but NOT the people developing, testing, or using the system.

*BONUS FEATURE: Acceptance tests provide some very valuable documentation of the functions and features of the system. The value of documentation will be addressed in a later post.

Entertained By Deception

2008-09-30T17:07:00.005-04:00

When you watch a movie and see dinosaurs chasing people across a field, do you think to yourself "That's pretty amazing!", or do you think to yourself "This isn't real."?

When you watch a magician perform on stage and step out from a tiny little box that could not possibly fit the magician's body, do you think to yourself "That's pretty amazing!", or do you think to yourself "This isn't real."?

When a movie showcases special effects, or a magician performs on stage, the deception of the senses leads to amazing entertainment. If we later learn how the movie's special effects were created, or we wrap our brains around figuring out just how did that magician appear out of that tiny little box, the amazement subsides. We may be impressed by the special effects methods, or impressed by our own explanation of the magician's work, but we are no longer nearly as amazed or entertained. We arrive at "This isn't real."

Behaviorally, we suspend disbelief and allow the deception to amaze us and entertain us, and it can be a thrilling experience. Knowing that we can be thrilled in this way, this may explain why we suspend disbelief when we invest in and follow the financial and housing markets. We all want that thrill, so we suspend disbelief: we don't learn how the investments are being made, how the investments are constructed, who is constructing them, or even wrap our brains around figuring out just how did house prices rise 10% during the year. We are happy just to allow the deception of sharp upward market movements to amaze us and provide us with a thrill.

But after the movie, or after the magic show, if someone came up to us and said "Hey, that wasn't real, you know.", we would respond "Yeah, so?" without feeling like we were suddenly slapped back into reality. So then why in 2008, when someone came up to us and said about the financial and housing markets "Hey, that wasn't real, you know.", we feel like we've been slapped?

The next time you watch the financial and housing markets climb so quickly and steeply that they lead to record highs in record time, will you still think to yourself "That's pretty amazing!", or will you think to yourself "This isn't real."?

The Exception-Tolerant Organization

2008-09-29T12:15:00.001-04:00

Everyone by now knows of the Pareto 80/20 rule and where it applies to conducting business on a daily basis: people spend 80% of their effort on 20% of the issues. Many of these issues are exceptions to the normal course of business, and do warrant greater attention and effort. But the 80% of the effort spent begins to take away attention and resources from handling the “normal” 80% of the issues a business faces on a daily basis, the very issues that keep the business alive. This can manifest itself in an organization slowly at first, like an insidious virus that attacks from the inside out.

By the time an organization realizes that its ability to handle the “normal” issue has been compromised, the gross margins have declined and the organization has lost its competitive edge. But an Exception-Tolerant Organization has learned to rise above this, to make 100% of their effort effective on 100% of their issues while keeping pace with changing conditions. This post introduces the Exception-Tolerant Organization (ETO), and subsequent posts will cover the major principles in greater detail.

First, what does it mean to be Exception-Tolerant? Today’s management consultants and management thought leaders preach the mantras of embracing change and embracing uncertainty. Being able to embrace change and embrace uncertainty are indeed important. But being Exception-Tolerant is about taking these embracements and bringing them into the practicality of day-to-day business. Being Exception-Tolerant is not about solely reacting to business events and then making on-thy-fly adjustments into your workflows and systems just to keep above the water level.

Exception-Tolerant Organizations:

- embrace change and uncertainty while systematically executing their business

- build the communication pathways, business processes, and technology features to handle exceptions systematically

- emphasize their strengths and compensate for weaknesses by working together and communicating openly

- practice daily Risk Management

- do not tolerate waste, stifling of innovation, or inflexibility

In other words, are they proactively built to execute during times of change, uncertainty, and exception? Or do they solely react?

Do you want your organization to be an Exception-Tolerant Organization?

Getting Our Hands Dirty

2008-09-24T13:44:00.005-04:00

During my career I've gained deep experience with financial software development, management, and leadership. But for many years I also provided on-call after-hours and overnight system support, first on a rotating-schedule basis, then 24/7/365. From this I learned the most critical details of what works and what does not work regarding data architecture, data transmission, business workflow, information flow, and human communication pathways within an organization. Learning these critical details often requires us to get our hands dirty, as this true story demonstrates:

One company’s hot-stove issue of the day was the paper problem: "We're spending so much on paper! Most of our paper reports are printed overnight at 5 am. Why do we print out so many reports overnight?" To be sure, this problem represented a sizable cost during a company’s belt-tightening period that required the Business and IT to conscientiously team together to get to the heart of the issue.

The long-tenured business-side Managing Director and the recently-hired CTO sat in the same room with a few key people from both Business and IT, to discuss the issue with the overnight support specialist responsible for collating and distributing the reports. After a few discussions on the purpose of the reports and the distribution lists, no clear solutions were presented. It was then the CTO declared, “Well if I have to come in at 5 am and see what is going on myself, then that’s what I’m going to do!”

A week passes by. Did the CTO make a call to action, or come in at 5 am? No - not even once. But one developer did not have to come in at 5 am to examine the company’s internal report-generation schedule and discover several large reports being generated and printed in duplicate, all delivered to the same recipient. In just a few hours after that meeting, the development team removed the duplicates from the report-generation configuration, alleviating some of the printing headache and cost beginning with the next night’s report run.

But the developer went further than that, as he had done previously when investigating IT problems in his company - he DID come in overnight and got his hands dirty. He sat with the overnight support specialist and analyzed when the reports were actually electronically delivered, how the specialist was collating and distributing the reports, and documented their purpose. After reviewing the developer's findings, the Managing Director agreed that most of the non-duplicate printing and distribution justified the cost for the time being, until the Business could get a paper-less business process in place.

When the buzz of the CTO’s declaration died down, the CTO was not willing to get his hands dirty. And what could have been a defining and inspiring leadership moment ended up being an action-less statement. But one developer took the lead, providing some immediate relief, but also investigating the problem in-depth and providing a basis for discussing a long-term solution. The developer was recognized by the Business for his leadership, while the CTO moved on from the company shortly thereafter.

The developer here learned that getting your hands dirty can produce results, and that leadership often requires that we get our hands dirty when investigating problems and formulating solutions. As today’s Leader – are you willing to get YOUR hands dirty?

The Intersection of Business and Technology

2008-09-21T11:19:00.002-04:00

What does the Intersection of Business and Technology look like?

Is the Intersection a shining Emerald City, where goals, ideas, and feedback are freely shared? Where IT principals understand the business and drive the technology to satisfy the business first, even before designing and deploying Greatest System Ever v10.0? Where business principals are sympathetic to the needs and specifications required for effective IT? Where regular partnership and joint accountability are merely business-as-usual, rather than a rarely-employed practice?

Is the Intersection a tall and wide impenetrable wall, where business goals are not shared, but volleyed back and forth between Business and IT? A place where business principals throw their problems over the wall as they hope and wait for a technology solution – any technology solution - to their operational problems and inefficiencies? Where the business principals rejoice when something – anything - has been thrown back over the wall for the first time in weeks or months? Is what they receive a true solution to their problems, or is it merely what the IT principals dictated as sufficient for the business without the ability or willingness to deliver more?

Is the Intersection a single blinking yellow traffic light, encouraging people to slow down but not stay around long enough to take a good hard look at what is being achieved or what is even possible? Or is the Intersection merely a desolate, unvisited crossroads whose only sign of activity is a tumbleweed traversing in the breeze?

When organizations establish their own Intersections, many treat the process like it is a Burning Man festival – that is to say, an exercise in temporary community. Principals from both Business and IT congregate for a few days to a week - often offsite - where they proclaim cooperation through rigorous presentations and sessions, show off their latest projects and business plans, share meals and shake hands, and then disband. When they return to their places of work, they often end up going back to the same or older practices, procedures, and policies - without making much progress. The partnerships do not survive the offsite event, and the joint accountability never materializes.

What does the Intersection of Business and Technology look like in your organization? How do you want it to look? Do you want merely the synergy of the temporary community without further partnership, the safety and protection from accountability that the impenetrable wall provides, or the shining Emerald City?

However you want the Intersection to look, one thing is certain: much like the Burning Man festival, the Intersection will contain only what you take with you.

A blog is born...

2008-09-16T22:38:00.007-04:00

Welcome to my latest venture! This is the place to read about and discuss why effective leadership in uniting Business and IT goals and groups is so crucial for organizations, as they thrive and work to maintain their edge in a competitive marketplace.

This blog will cover:

- topics on leadership and unity of Business and IT groups of thriving organizations

- real-world anecdotes of effective (and not-so-effective) technology and business leadership

- people profiles and topics, to consider some outside viewpoints

- what it means to be an Exception-Tolerant Organization (ETO). I will flesh out this concept and its principles and practices in the coming days.

Who should read this blog:

- technologists of all levels looking to make a greater impact in their work and their organizations, and actively working to sharpen their growing edge of leadership

- business owners, executives, managers, and associates seeking more fulfillment and assistance from their IT groups and partners in accomplishing their business objectives

I hope that the blog will provide insight and open up a dialogue to improve leadership at all levels of an organization as we face the challenges ahead of us in the rest of 2008 and beyond.

Happy Reading!
Jason Sliss