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.
Tuesday, June 2, 2009
Wednesday, May 13, 2009
Considering the Exception-Tolerant Organization in 2009
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.
For more on the Exception-Tolerant Organization, please see this post.
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.
For more on the Exception-Tolerant Organization, please see this post.
Tuesday, May 5, 2009
Letting Go Of The Past
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?
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
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.
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.
Friday, March 20, 2009
Turning Cost Centers Into Cost Savers
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?
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?
Tuesday, March 10, 2009
Communities Are A New Leadership Currency
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.
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.
Wednesday, February 18, 2009
Resolving our Top Priorities
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.
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
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?
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?
Wednesday, February 4, 2009
Lasting Improvements in Technology
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.
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.
Wednesday, January 14, 2009
Business Acclimation to New Technology
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.
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.
Tuesday, January 13, 2009
Agile Success During Challenging Times
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.
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.
Monday, January 5, 2009
Leading the Way In Technology and Business For 2009
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?
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
Subscribe to:
Posts (Atom)
