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?
Friday, March 20, 2009
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.
Subscribe to:
Posts (Atom)
