Recently while reading a book by the Dalai Lama, I came across a passage that said the essence of his teachings is to help others if possible, and if that is not possible, at least do no harm. While Tibetan Buddhism and technology have little in common, this passage can also be considered the essence of good technology planning.
The goal of a business is to increase profitability. A profitable company creates jobs, purchases more equipment from vendors and adds overall value to the community. Any tool used by the business - whether it is in technology, manufacturing or office service - should enhance a company's revenue stream or at the least do no harm.
Technology is a valuable tool for enhancing the bottom line, but it also can affect the profit margin negatively. Good technology planning has to include a thorough financial and risk analysis to determine the true value of a technology, for often there is more than meets the eye.
A good example of this is Internet-based VPNs. Many companies are using VPNs as alternatives to costly dedicated circuits as in many cases, they can reduce network costs by 20% to 30%. At first glance, this would appear to meet the goal of enhancing a company's profitability. However, this is a case in which technology planners need to consider the risk.
Internet-based VPNs do reduce cost; however they often carry a lower service level from the vendor. Most Internet-based VPNs utilize DSL and most DSL providers have a minimum mean time to repair (MTTR) of 24 to 48 hours. Often this is only Monday through Friday which means an outage on Thursday afternoon might not be resolved until Tuesday - a five day disruption to the revenue stream that can more than eliminate any network cost savings. If the downtime happens during a company’s busy season, the result could be financially devastating. Granted the risk can be reduced by providing additional dial or ISDN backup, but then the overall cost of the solution might reduce the potential savings to a level that is not financially justifiable.
Internet-based VPNs can be the network of choice for locations that generate little or no revenue; however the risk to the revenue stream needs to be considered before migrating any revenue-generating location away from dedicated connectivity.
VPNs are not the only technology that needs to be analyzed in this manner. Any network, systems or application technology that has the potential to affect a company's revenue stream needs to be evaluated thoroughly to ensure it enhances profitability or at least does no harm.
Sunday
Monday
The Best Laid Plans Of Mice And Men
"The best laid plans of mice and men often go awry, and leave us nothing but grief and pain instead of promised joy." These words form the great poet Robert Burns' sum up the sentiments many managers have about projects that started strong but ended miserably.
IT has its share of best laid plans that go awry. From complex CRM implementations that come in grossly over-budget to resource-consuming data warehouses that lie dormant to costly vendor-touted technologies such as ATM that are quickly superseded by newer and faster products, IT often has an inordinate amount of highly visible projects that end miserably.
The issue is not that these technologies are overrated (with the possible exception of ATM); rather the problem is that the IT planning process is often anything but best laid.
In the late 1990s, there was a growing focus on strategic technology planning. Many organizations created in-house technology architecture groups that focused on integrating the application, system and network planning. These groups were tasked with ensuring that the networks being deployed facilitated the applications being developed, which in turn were analyzed to ensure the correct systems were being deployed. The entire process was business-driven, ensuring the overall IT architecture met business goals.
After the dot-com bubble burst in the early 2000s, companies downsized IT and many architecture groups were disbanded. The planning focus of many companies shifted to point solutions that met short-term operational needs - which in itself isn’t a bad strategy. Unfortunately, many IT managers associated point solutions with "no planning needed," so the IT planning process diminished drastically.
Now don’t get me wrong, IT organizations still make plans. Most IT departments have a strategic vision and develop detailed individual project plans. But what's missing is the crucial planning step that occurs between the strategic vision and the project implementation plans. This is the area I call the "IT blueprint." The strategic vision states where IT is going. The blueprints detail how IT gets there: what initiatives need to be implemented, when they need to be implemented, what resources will be needed, how much funding will be required and how the various projects fit together to reach the overall IT strategic goal.
This level of planning is critical to the successful implementation of new technologies. Take VoIP as an example. Many companies have VoIP as a strategic goal and most of these companies have specific project implementation plans for VoIP. However, without an overall IT blueprint that shows where VoIP fits into the overall tehnology architecture, what applications will utilize it, what business units will benefit from it, what vendors will be utilized, how it will interface with the data network, and what the overall financial implications are in terms of timing and deployment, VoIP may wind up being another best laid plan that ultimately goes awry.
An IT blueprint is similar to the blueprint of a house. An architect might have a wonderful concept and each subcontractor might have individual detailed plans for plumbing, electricity and carpentry, but without a blueprint showing how everything fits together, the house will never materialize.
An IT infrastructure built without proper planning - whether from mice or men - is doomed to become another plan gone awry.
IT has its share of best laid plans that go awry. From complex CRM implementations that come in grossly over-budget to resource-consuming data warehouses that lie dormant to costly vendor-touted technologies such as ATM that are quickly superseded by newer and faster products, IT often has an inordinate amount of highly visible projects that end miserably.
The issue is not that these technologies are overrated (with the possible exception of ATM); rather the problem is that the IT planning process is often anything but best laid.
In the late 1990s, there was a growing focus on strategic technology planning. Many organizations created in-house technology architecture groups that focused on integrating the application, system and network planning. These groups were tasked with ensuring that the networks being deployed facilitated the applications being developed, which in turn were analyzed to ensure the correct systems were being deployed. The entire process was business-driven, ensuring the overall IT architecture met business goals.
After the dot-com bubble burst in the early 2000s, companies downsized IT and many architecture groups were disbanded. The planning focus of many companies shifted to point solutions that met short-term operational needs - which in itself isn’t a bad strategy. Unfortunately, many IT managers associated point solutions with "no planning needed," so the IT planning process diminished drastically.
Now don’t get me wrong, IT organizations still make plans. Most IT departments have a strategic vision and develop detailed individual project plans. But what's missing is the crucial planning step that occurs between the strategic vision and the project implementation plans. This is the area I call the "IT blueprint." The strategic vision states where IT is going. The blueprints detail how IT gets there: what initiatives need to be implemented, when they need to be implemented, what resources will be needed, how much funding will be required and how the various projects fit together to reach the overall IT strategic goal.
This level of planning is critical to the successful implementation of new technologies. Take VoIP as an example. Many companies have VoIP as a strategic goal and most of these companies have specific project implementation plans for VoIP. However, without an overall IT blueprint that shows where VoIP fits into the overall tehnology architecture, what applications will utilize it, what business units will benefit from it, what vendors will be utilized, how it will interface with the data network, and what the overall financial implications are in terms of timing and deployment, VoIP may wind up being another best laid plan that ultimately goes awry.
An IT blueprint is similar to the blueprint of a house. An architect might have a wonderful concept and each subcontractor might have individual detailed plans for plumbing, electricity and carpentry, but without a blueprint showing how everything fits together, the house will never materialize.
An IT infrastructure built without proper planning - whether from mice or men - is doomed to become another plan gone awry.
Planning For Chaos
The project appeared to have all the ingredients for success: implementing a consolidated campus network would generate a 30% reduction in monthly telecom bills; capital costs were less than $500,000; senior management endorsed the project and all the required resources; the work breakdown schedule was thoroughly documented; and the critical path had been identified.
Nothing should have gone wrong. Yet when the project was completed, it came in over budget and behind schedule. New hardware requirements for video connectivity and remote access were added at the last minute and although they were approved by the CIO, the change resulted in cost overruns of nearly $200,000. Early snowstorms delayed the fiber installation as union rules prohibited the phone company from removing snow from manhole covers. Equipment was delayed due to manufacturing and shipping backlogs which resulted in additional implementation delays. Even though management was kept informed of the delays and understood the reasons, by the time the network was finally live it was a bittersweet success at best.
No matter how much we plan, unforeseen events can create havoc with a project's budget, scope and timeline. And according to Chaos Theory, this is inevitable. For in our seemingly orderly world, one of the fundamental processes that pervade our universe is chaos. The philosopher Friedrich Nietzsche noted that "out of chaos comes order," and modern day theorists such as James Gleick believe chaos is the breeding ground of order.
If you extrapolate the philosophical and theoretical into the practical, it might be impossible to avoid chaos. So instead of trying to deny it, we should plan for it and even cultivate a controlled chaos to achieve the order we seek.
Ten years ago, a typical IT project consisted of a series of predictable events: identify a need, develop a solution, write and approve a business case, assemble a project team, develop a project plan, approve the budget and launch the project. A project was considered a success if it came in on time and under budget.
Today the pace of business has quickened and overall timelines have shortened drastically. The sequential events of yesterday have been replaced by the parallel events of today. Business cases often need to be written while solutions are being developed. Project timelines need to be created before all the tasks and resources have been completely identified.
This new fast-paced paradigm is a breeding ground for chaos. Project teams need to be able to respond to changing events quickly. Alternate solutions need to be ready in the event the proposed solution can’t be implemented or doesn’t work. Backup resources need to be identified in case key resources leave the company. Potential cost reduction opportunities need to be identified in the event business conditions dictate across the board budget cuts.
Project teams – and the managers that lead them – need to be more flexible and creative than ever before. As noted in an earlier post, my own philosophy is that a project manager should be like a sheepdog. Sheepdogs set up a boundary for the flock, allow a certain amount of freedom within that boundary and nip the heels of those who try to cross the boundary. Instead of trying to control the individual sheep, the sheepdog focuses on moving the entire flock to the stated goal.
When I lead a project or initiative, I seek the expertise of others, request their input into key decisions and give them control over aspects of their job. Like a sheepdog, I set the project boundaries, but allow a certain amount of controlled chaos to reign in solutions development and implementation.
A few years ago I was handed a VPN project that was in development and already behind schedule. In order to reap the anticipated cost savings, the solution needed to be implemented quickly. My job was to bring it back on track and implement it in the required timeframe. The short time frame necessitated creating a revised business case, engineering design and project plan in parallel.
Instead of trying to control every aspect of the project, I set the overall boundaries, then allowed a lot of chaotic movement within those boundaries and nipped the heels as needed to keep the team moving toward the goal.
I involved the project team in brainstorming various scenarios to develop risk-mitigation plans. We identified and documented the assumptions used, and worked to ensure project sponsors and senior management were aware of all timeline and budget risks.
During network planning sessions I cultivated controlled chaos and allowed a free exchange of ideas, sometimes playing devil's advocate to insure all options were reviewed. When discussions wandered off the track or became personal, I would nip heels as needed to bring everyone back into focus.
Even after an initial vendor decision had been made on hardware, I accommodated additional chaos to incorporate newly available equipment from a different vendor that brought added value, but required a redesign of ordering, shipping and configuration processes.
From the outside the project often appeared to be in total disarray. There were times when the proposed design changed on a weekly - and sometimes daily - basis. I had to meet many times with the project sponsors to assure them everything was OK.
I let chaos reign, but it was controlled chaos. Like sheepdogs, I constantly circled the team making sure that timelines were met, solutions were in scope and equipment was in budget. Ultimately, out of the chaos came order.
By both planning for chaos and cultivating controlled chaos the project team implemented a solution within 120 days of final budgetary approval that not only met all customer requirements, but also provided a scalable platform that would accommodate future growth. Nietzsche would have been proud.
Nothing should have gone wrong. Yet when the project was completed, it came in over budget and behind schedule. New hardware requirements for video connectivity and remote access were added at the last minute and although they were approved by the CIO, the change resulted in cost overruns of nearly $200,000. Early snowstorms delayed the fiber installation as union rules prohibited the phone company from removing snow from manhole covers. Equipment was delayed due to manufacturing and shipping backlogs which resulted in additional implementation delays. Even though management was kept informed of the delays and understood the reasons, by the time the network was finally live it was a bittersweet success at best.
No matter how much we plan, unforeseen events can create havoc with a project's budget, scope and timeline. And according to Chaos Theory, this is inevitable. For in our seemingly orderly world, one of the fundamental processes that pervade our universe is chaos. The philosopher Friedrich Nietzsche noted that "out of chaos comes order," and modern day theorists such as James Gleick believe chaos is the breeding ground of order.
If you extrapolate the philosophical and theoretical into the practical, it might be impossible to avoid chaos. So instead of trying to deny it, we should plan for it and even cultivate a controlled chaos to achieve the order we seek.
Ten years ago, a typical IT project consisted of a series of predictable events: identify a need, develop a solution, write and approve a business case, assemble a project team, develop a project plan, approve the budget and launch the project. A project was considered a success if it came in on time and under budget.
Today the pace of business has quickened and overall timelines have shortened drastically. The sequential events of yesterday have been replaced by the parallel events of today. Business cases often need to be written while solutions are being developed. Project timelines need to be created before all the tasks and resources have been completely identified.
This new fast-paced paradigm is a breeding ground for chaos. Project teams need to be able to respond to changing events quickly. Alternate solutions need to be ready in the event the proposed solution can’t be implemented or doesn’t work. Backup resources need to be identified in case key resources leave the company. Potential cost reduction opportunities need to be identified in the event business conditions dictate across the board budget cuts.
Project teams – and the managers that lead them – need to be more flexible and creative than ever before. As noted in an earlier post, my own philosophy is that a project manager should be like a sheepdog. Sheepdogs set up a boundary for the flock, allow a certain amount of freedom within that boundary and nip the heels of those who try to cross the boundary. Instead of trying to control the individual sheep, the sheepdog focuses on moving the entire flock to the stated goal.
When I lead a project or initiative, I seek the expertise of others, request their input into key decisions and give them control over aspects of their job. Like a sheepdog, I set the project boundaries, but allow a certain amount of controlled chaos to reign in solutions development and implementation.
A few years ago I was handed a VPN project that was in development and already behind schedule. In order to reap the anticipated cost savings, the solution needed to be implemented quickly. My job was to bring it back on track and implement it in the required timeframe. The short time frame necessitated creating a revised business case, engineering design and project plan in parallel.
Instead of trying to control every aspect of the project, I set the overall boundaries, then allowed a lot of chaotic movement within those boundaries and nipped the heels as needed to keep the team moving toward the goal.
I involved the project team in brainstorming various scenarios to develop risk-mitigation plans. We identified and documented the assumptions used, and worked to ensure project sponsors and senior management were aware of all timeline and budget risks.
During network planning sessions I cultivated controlled chaos and allowed a free exchange of ideas, sometimes playing devil's advocate to insure all options were reviewed. When discussions wandered off the track or became personal, I would nip heels as needed to bring everyone back into focus.
Even after an initial vendor decision had been made on hardware, I accommodated additional chaos to incorporate newly available equipment from a different vendor that brought added value, but required a redesign of ordering, shipping and configuration processes.
From the outside the project often appeared to be in total disarray. There were times when the proposed design changed on a weekly - and sometimes daily - basis. I had to meet many times with the project sponsors to assure them everything was OK.
I let chaos reign, but it was controlled chaos. Like sheepdogs, I constantly circled the team making sure that timelines were met, solutions were in scope and equipment was in budget. Ultimately, out of the chaos came order.
By both planning for chaos and cultivating controlled chaos the project team implemented a solution within 120 days of final budgetary approval that not only met all customer requirements, but also provided a scalable platform that would accommodate future growth. Nietzsche would have been proud.
Sunday
Sheepdog management: nip their heels and keep 'em moving
As a manager, I have experimented with a number of management theories and strategies. I have tried micromanagement, delegation and empowerment. I've experimented with Theory X management techniques - "crack the whip" - and Theory Y techniques - "you love your job and want to work so I'll just leave you alone." I've had resounding success with some techniques and dismal failures with others. What works for one project or team may not work for another.
In an ongoing attempt to see if there is one single management technique that can be used across the board, I've studied management theorists, philosophers, psychologists, military leaders and most recently man's best friend - the dog. Specifically, the sheepdog. And while it may sound strange that a sheepdog could teach us anything about management, in reality they may be a stellar example of an effective team leader. By looking at how a sheepdog interacts with its flock, we managers may be able to learn a few things about how to herd our own “cats”.
When you watch a sheepdog, the first think you notice is that the sheepdog does not try to manage each sheep individually. Instead of micromanaging individuals, the sheepdog focuses on moving the entire flock toward the desired goal. He (or she) does this by setting up boundaries, keeping the flock within those boundaries and nipping at the heels of stragglers to get them moving. However, within the boundaries of the flock there is a great degree of freedom to move about and the sheepdog allows this "chaos in motion” to happen.
Staff personnel are a lot like a flock of sheep in this regard. Each individual needs a certain amount of freedom. Employees want to have their voices heard, their experience respected and their knowledge utilized. Additionally, many want to have a certain amount of control over their work life. Whether it is control over their work hours, their PCs, their cubicles, or how they write their status reports, most creative people want – and need – some level of control.
Managers who try to use a “command and control" style of management may find they are doomed to failure. Just as a flock of sheep scatters when a wolf dives into the middle of it, so too will a team of creative, productive people scatter when a manager dives in and tries to exert control over every aspect of their work.
Early in my management career, I was pressured by new leadership to implement a command and control mode to "whip the troops into shape." And the results were dismal. Morale dropped, key personnel left and the remaining staff became bitter and uncooperative. After I convinced my management to let me loosened the reins I started having success; however it took a significant amount of time to rebuild a good working relationship.
Successful leaders acknowledge their team's expertise, respect their opinions, request and use their advice, and provide an atmosphere that is conducive to creative expression. Some of my most successful projects have involved teams that from the outside appeared to be very chaotic. And in truth, there was a certain amount of chaos. In fact, I even encouraged it. Chaos is nothing more than creativity in action. As the philosopher Nietzsche said, "Out of chaos comes order."
Successful managers do not try to control their teams. Like the sheepdog, these leaders establish realistic boundaries, allow their teams the freedom to move about within those boundaries, and work to move the team as a whole to the stated goal. They may have to circle the flock and nip the heels of stragglers every now and then, but their focus is on guiding, not controlling.
(This is an update to a column I originally wrote for Network World in 2001. The original article is copyright 2001 by Network World, Inc., 118 Turnpike Road, Southboro, MA 01772. Reprinted from Network World.)
In an ongoing attempt to see if there is one single management technique that can be used across the board, I've studied management theorists, philosophers, psychologists, military leaders and most recently man's best friend - the dog. Specifically, the sheepdog. And while it may sound strange that a sheepdog could teach us anything about management, in reality they may be a stellar example of an effective team leader. By looking at how a sheepdog interacts with its flock, we managers may be able to learn a few things about how to herd our own “cats”.
When you watch a sheepdog, the first think you notice is that the sheepdog does not try to manage each sheep individually. Instead of micromanaging individuals, the sheepdog focuses on moving the entire flock toward the desired goal. He (or she) does this by setting up boundaries, keeping the flock within those boundaries and nipping at the heels of stragglers to get them moving. However, within the boundaries of the flock there is a great degree of freedom to move about and the sheepdog allows this "chaos in motion” to happen.
Staff personnel are a lot like a flock of sheep in this regard. Each individual needs a certain amount of freedom. Employees want to have their voices heard, their experience respected and their knowledge utilized. Additionally, many want to have a certain amount of control over their work life. Whether it is control over their work hours, their PCs, their cubicles, or how they write their status reports, most creative people want – and need – some level of control.
Managers who try to use a “command and control" style of management may find they are doomed to failure. Just as a flock of sheep scatters when a wolf dives into the middle of it, so too will a team of creative, productive people scatter when a manager dives in and tries to exert control over every aspect of their work.
Early in my management career, I was pressured by new leadership to implement a command and control mode to "whip the troops into shape." And the results were dismal. Morale dropped, key personnel left and the remaining staff became bitter and uncooperative. After I convinced my management to let me loosened the reins I started having success; however it took a significant amount of time to rebuild a good working relationship.
Successful leaders acknowledge their team's expertise, respect their opinions, request and use their advice, and provide an atmosphere that is conducive to creative expression. Some of my most successful projects have involved teams that from the outside appeared to be very chaotic. And in truth, there was a certain amount of chaos. In fact, I even encouraged it. Chaos is nothing more than creativity in action. As the philosopher Nietzsche said, "Out of chaos comes order."
Successful managers do not try to control their teams. Like the sheepdog, these leaders establish realistic boundaries, allow their teams the freedom to move about within those boundaries, and work to move the team as a whole to the stated goal. They may have to circle the flock and nip the heels of stragglers every now and then, but their focus is on guiding, not controlling.
(This is an update to a column I originally wrote for Network World in 2001. The original article is copyright 2001 by Network World, Inc., 118 Turnpike Road, Southboro, MA 01772. Reprinted from Network World.)
Subscribe to:
Posts (Atom)