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.
Wednesday, January 14, 2009
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)
