Thursday, January 31, 2002

 
Posted by Mike Tarrani 6:29 PM
One thought leads to another. In my 31 January entry that I posted at 3:51 AM in Notes from the Field I discussed LDAP, role-based access controls (RBAC) and software QA. The only apparent tie-in among the topics was the relationship between LDAP and RBAC. I'm going to step back onto the soapbox and discuss a real-life relationship among LDAP, RBAC and QA. The names have been changed to protect confidentiality.

Background

The company for which I was working had developed a security infrastructure that used directory services, policy servers and other components to achieve a single sign-on, enterprise-wide infrastructure that was independent of applications and platforms. On paper it looked viable. The first customer was one of the largest manufacturers in the world.

According to company lore the client's CIO bought into this design based on a one-hour presentation. With authority to proceed in hand a small team descended upon the client's site and commenced implementing this panacea.

Fast forward to a different client half-way around the world. We were not tasked with implementing the same solution, but were tasked with including a recommendation for a security infrastructure in a strategic plan. The plan was to be a 5-year roadmap for how the technical and process domains were to evolve. In went the untested and unproven security infrastructure that was still being implemented for the international manufacturer.

I'm going to jump back to the project for the international manufacturer: my involvement in that project was to bring the portions that touched UNIX systems into production. I was a consultant serving as a member of the client's production services team. I was working for a different company at the time and was an on-site consultant who was hired away by the company that developed the security infrastructure - what a tangled web we weave.

When I was assigned to the strategic planning project half-way around the world I was no longer directly involved in the first project. However, when I was involved I noted (in writing to the client) that there was no testing done on a system upon which the client was depending for security. Moreover, the entire infrastructure could be bypassed if there were no guidelines for integrating new systems into the infrastructure. Finally, nobody had taken the time to assure that access controls were provably correct; there was no mathematical analysis of the design, nor were there any test plans or cases with which to validate new applications being integrated into the environment.

Two glaring problems surfaced with respect to this unproven scheme:

1. The products upon which the architecture was built had flaws. One reported incident allowed a user to assume the more extensive rights of another user. This was swept under the carpet by a statement by the CEO of my new company that, "it's such a rare bug that it will not happen again." Product qualification and design testing would have caught that.
2. In the strategic plan that was drafted before I joined the other project, the recommendations were for products instead of standards. This goes against all that is sacred in IT strategic planning, which is supposed to be based on solutions and standards - not products.

Results

The following occurred:

1. The company at which I landed was thrown out of the international manufacturer, and the project handed to another consulting company. Ironically, it wasn't because of the flaws I cited above - it was because of poor project management and other reasons that are not germane. In defense of the company that lost the project, I'll say that the client was as much to blame for project management deficiencies, and certainly deserves a share of the blame for approving a project that was built on such a shaky and untested foundation.
2. Something different happened with the second client - they were quick to complain about the fact that products, not solutions and standards, were included in the strategic plan. They wanted alternatives as well as an in-depth strengths/weaknesses/opportunities/threats (SWOT) analysis performed on our initial recommendations and the alternatives. This was handled by rewriting the strategic plan, eliminating product recommendations and replacing them with standards.

Lessons Learned

1. Never buy into a solution, especially one as critical as an enterprise security infrastructure, without a copious amount of due diligence. Among the actions that the international manufacturer's CIO should have taken or caused to be taken are:
   • Investigated the company before buy-in - suffice to say that some probing reference checks may have raised red flags
   • staffed out to in-house experts (security, architecture and production services) an analysis of the proposed solution. Issues and factors, such as the use of Novell's NDS, would have elicited concerns (Novell products were on the forbidden list per standards and policies), and the production acceptance requirements would have been made known to all stakeholders - an omission that triggered schedule and cost overruns later in the project because they were not taken into account.
   • ensuring that products cited in the solution were investigated and there were provisions for a functional qualification test. An example of what happens when such steps are not taken is illustrated in a recent report about Microsoft Passport flaws (see also another horror story).
   • no business case. A decision was made based on a presentation without any business case to prove the value. In my opinion this debacle was created on the back of a cocktail napkin. I'm sure a PowerPoint presentation was also involved.
2. Formal proof of design for critical infrastructure components is essential. Enterprise-wide directory services depend on role-based access controls, which need to be designed and validated using set theory. To the best of my knowledge nobody on the client or vendor side had the skills or knowledge to undertake this.
3. If an important part of an architecture touches everything then test plans and cases need to be developed. If not specific plans and cases, a framework and templates that can be tailored are the bare minimums. Needless to say, this was not done.
4. In the case of the strategic plan, there are also lessons to be learned. Among them:
• Never base a strategy on a product - especially a long-range strategy. Products come and go, they evolve quickly, and are not a proper foundation. Standards, on the other hand, change slowly (if at all), and serve as a basis for a solid architecture.
• Extensive investigation is required, as is traceability. If you're doing strategic planning you need to:
  • explore alternatives
  • assess the strengths and weaknesses (as well as the opportunities and threats) of those alternatives
  • document how you arrived at your recommendations and why
  • trace back technical decisions to business requirements
  • cite references that support your projections (i.e., Meta Group, GartnerGroup, etc.)

Postscript added at 17:56 PST: See related article that reinforces what I wrote above.

Wednesday, January 30, 2002

 
Posted by Mike Tarrani 5:50 PM
An interesting and coherent view of IT business alignment and core service delivery processes is depicted in the Leveraged Management of IT Assets that is a State of North Carolina initiative. This diagram validates my own assertions about elements for success.

Two papers that add to the IT/business alignment body of knowledge are Connecting IT Theory with Industry Best Practices and Quantifying IT Benefits.

I also recommend Collaborative Information Systems Development, which is a page that is rich in content with the underlying theme of unifying IT into a team. This is a step up from most IT organizations, which are too often independent and warring factions that work at cross purposes.

 
Posted by Mike Tarrani 3:51 AM
The goal of this weblog is to hold up a mirror and make sure that the image looking back is what we expect of IT professionals. Be aware, though, that while our profession has a tarnished reputation in the eyes of the business users that we support, our clients can sometimes lead us astray. M. E. Kabay's Network World Security Newsletter article, The Equity Funding fraud shows how IT can be duped if we don't maintain the highest sense of ethics and understand how the business we're supporting works. There's a lesson in the article for all of us.

 
Posted by Mike Tarrani 3:19 AM
This entry is a continuation of my 26 January entry. I stated that successfully balancing rigid methodologies against an agile IT function is possible as long as seven essential elements are retained.

IT needs to be able to quickly move to meet emerging business requirements. However, processes that assure success are critical and cannot be tossed aside in the name of agility. IT operational excellence from the user (business) point of view is measured by how well or poorly IT delivers service. There are many moving parts to service delivery, as well as interfaces into applications delivery and other areas. Linda and I developed one organizational model that ties together these functions. We make no claims that it's perfect, but it does represent best practices that she and I have collected in our collective half-century in the industry. In addition, the META Group has a PowerPoint presentation titled, A Framework for Operational Excellence that contains a rough roadmap to achieving world-class IT operations.

Another area that many IT organizations appear to fully understand is problem management. This process is enterprise-wide--not just a fancy term for a help desk. A narrow, but valid, view of problem management is shown in a PowerPoint presentation titled Problem Management: What is it Good For? I also found the following PowerPoint presentation on ITIL Service Level Management as a realistic approach to enterprise-wide problem management. A wider view of this critical process can be found in IT Problem Management by Harris Kern and Gary Walker. Linda and I have both reviewed this book on Amazon. In fact, she and I have reviewed all of the books in the Harris Kern Enterprise Computing Series.

I hope this entry sparks ideas and provides interesting reference material. At some point I am going to jump in and address configuration, change and release management in detail (and I have a ton of material that I've developed to back it up). Until then, digest this and let us know if we are on track.

Tuesday, January 29, 2002

 
Posted by Mike Tarrani 4:28 AM
The theme of this entry is service level management and supporting processes. First stop is Service Management: Supplier's Perspective by Hewlett-Packard. This document gives an overview of the ITIL service level management framework and how it can fit within a supplier's strategy. Clarity Consulting has two interesting and brief articles. The first is titled Five Principles of SLAs, which sets the context for Metrics for IT Outsourcing Service Level Agreements.

Application Planet also has a well-written SLA whitepaper that is worth bookmarking. A gem in PDF format is SLA Management, which was first presented at Interop 2001. The ASP Alliance Chapter has related articles on service level management, the best of which (in my opinion) is SLA Draft Program Version 1.0. Although this draft is little more than an outline, it's useful for structuring your own SLA standard.

A paper in PDF format titled Service Level Management: A Requirements View bridges applications and service delivery aspects of service level management. An example of an application-specific SLA (for MS Exchange) is Blueprint for an Exchange Service Level Agreement. If you're using Exchange so much the better, however this document serves as a general model that fits many desktop applications.

SLAs: An Overview and the related paper, SLA Performance Metrics are foundation material for a service level management initiative that already has the basics in place. Along the same lines, Availability Metrics and The "Availability Gotcha" (or Why 99.999% Still Equals Nothing) are crammed with thought-provoking ideas and not a little debunking.

On the outsourcing side of the equation, Intel (of all companies) has an excellent online whitepaper titled Engaging and Managing Outsource Vendors for eBusiness. The FDIC has a set of guidelines that are aimed at financial institutions, but apply to any business, titled Tools to Manage Technology Providers' Performance Risk: SLAs. Two other documents that take a risk management approach to outsourcing is A Guide to the Critical Success Factors and SLAs and Hedging of Risks for Service Providers.

Great things come in pairs: Using Service Level Agreements for Competitive Advantage and Running IT Like a Business are a pair of documents that show how service level management is the key to IT proving its value to the business.

I'll end this with a touch of humor in the form of a complaint that two customers jointly wrote to a hotel chain. This complaint is unique because (1) it was not presented on one of those postcard-sized feedback forms, but instead was delivered as a PowerPoint Presentation and (2) it was written by two consultants who obviously do a lot of presentations. I don't personally know the two consultants--I came across this presentation from my close friend Kate Hartshorn (who is a PowerPoint wizard in her own right). What I do know is that smart, disgruntled customers can and will hold you accountable for the level and quality of service that you provide. Moreover, they should. While you're smiling at how the complaint was cleverly crafted and the hotel deserved such scathing feedback ask yourself how your customers view your organization. Enjoy.

Monday, January 28, 2002

 
Posted by Mike Tarrani 4:12 PM
Linda's last post has inspired me to dig up and share more checklists and resources that will add substance to my 26 January entry. That entry introduced seven essential elements for successfully balancing rigid methods with agility to meet goals in support of business imperatives. I left out specific examples, which Linda took the time to provide. Here are a few gems that I think are especially valuable to go with those that Linda shared:

• Assets and artifacts that support Kim Caputo's excellent book titled CMM Implementation Guide: Choreographing Software Process Improvement are a cache of Word documents that provide checklists, among other gems, that will prove helpful in a number of areas. Although Kim's book is about implementing the capability maturity model, the checklists can be used for other initiatives. Two of my favorites from this page are Project Management Review Process and Software Quality Assurance Process. If you want to know more about Ms. Caputo's book see my July 3, 2001 review on Amazon. If you need a top consultant for CMM implementation, training or business analysis visit Delta Business Solutions, which is her company web site.
• Software Risk Management: A Practical Guide is a complete and comprehensive resource for risk management. This document is in MS Word format and was developed by the Department of Energy. The concepts and approach in this guide can be aligned to project, operational, or quality risk management.
• Christine Comaford has a web site that contains a wealth of templates, checklists and presentations that you'll find to be extremely useful. Also check out her page of best practices, which are, indeed, representative of how to do the right things the right way.

Saturday, January 26, 2002

 
Posted by Mike Tarrani 7:41 PM

Give me the wisdom to change what I can change, Give me the wisdom to accept the things I can't change, Give me the wisdom to know the difference...
- Saint Francis of Assisi

This prayer, offered nearly 800 years ago, applies to challenges we IT professionals struggle with today.

The foremost challenge is the balancing act between due diligence and agility in project management and day-to-day operations. The conundrum is choosing between:

• rigid adherence to processes and procedures that may make the difference between competitive advantage and lost opportunity
• lack of controls and checkpoints that may result in disasters, such as scrapped projects, abysmal service levels and unreliable systems

Either way, business efficiency and effectiveness, and shareholder value suffer.

Is there a happy medium? The answer is an emphatic yes. The keys are having the wisdom to know the difference and a personal commitment to do something about it. My definition of wisdom is the synthesis of experience and knowledge that accrues from hard-learned lessons of what does and doesn't work and an ongoing regimen of keeping abreast of techniques, methods and best practices. The personal commitment part of the equation is a desire to do the right things for the right reasons.

Yes, my definitions sound lofty and idealistic, but I know from experience that they translate into a practical approach to striking a balance between rigid methodologies and flexible execution.

The first step in achieving that balance is to understand that what has evolved into methodologies, processes and procedures employed by rigid organizations is a small set of essential activities and a lot of non-value adding fluff. Unfortunately, when organizations find themselves hampered by methodologies when scrambling to meet business or technical goals and objectives they jettison the entire methodology, tossing out the small set of essentials with the fluff. In the short term things get done. In the long term things have to be redone - or fail altogether (and usually in spectacular ways).

What is this small set of essentials? There are seven essential elements. They are necessary regardless of whether the activity is project management, application development or service delivery. These are the seven essentials that will make the difference between success or failure:

1. Scope - unless the scope of a project or level of service is clearly defined and agreed upon by all stakeholders you can be sure that resources will be wasted on the nice-but-not-necessary. Scope is defined by goals and objectives (what are we attempting to do and why?), requirements (what do we need?) and available resources (given that we need x, y and z; but can only afford two of them, where will be get the most bang for our buck?). Tools to define scope include business needs statements, business cases, requirements documents (requirements, not specifications), trade-off analysis (specific tools include quality function deployment, strengths/weaknesses/opportunities/threats, and prioritization techniques), and a written statement (or scope) of work that is reviewed and approved by all stakeholders.
2. Change management - in projects this is a formal process for changing scope of a project. Software development uses software configuration management techniques to assure the integrity of the code base. In production or operations this is a process for managing changes to the system or application that supports business processes. With respect to organizations, this is the way processes are changed or introduced, thus changing the scope of responsibilities and activities. Regardless of whether the change is being applied to project scope, a system or application, or an organization or organizational unit, unless the change is managed something will fall through the cracks. Change management need not be a cumbersome or bureaucratic process with micro-managed procedures, but it does need to be governed by policy and outlined in the form of process and procedure. The best tools are the wealth of documented best practices that can be modified to meet a specific organization's needs for change management. Explore my web site for some of these documents and supporting tools.
3. Reviews and checklists - these are simple, incredibly effective and sorely missing from too many organizations. An activity as simple as a peer review will invariably catch errors that appear obvious once spotted, but in real life manage to migrate from one life cycle milestone to the next, eventually creating havoc in a production system. Checklists, in my opinion, are one of the most effective quality techniques available, and they have an added benefit of being simple and easy to use. The better checklists will have a column for expected results and action to take if something unexpected happens. A challenge is making sure people actually use the checklists. I could recite horror stories (and will in a future entry) about what happens when a well designed checklist is ignored. Another form of checklist is a work breakdown structure (WBS) that is the foundation of any well-planned project. True, a WBS is more like an outline than a checklist, but when all tasks are associated with deliverables, and estimates are performed using cost-estimating relationships and other methods, the WBS does begin to take on the form of a checklist.
4. Entry and exit criteria - think quality! Every process has entry criteria that needs to be satisified before the process is initiated, and exit criteria to determine whether or not the process produced whatever it is that is supposed to be produced within the framework of quality requirements. In TQM the tool is the Plan-Do-Check-Act (PDCA) cycle (sometimes modified to be Entry-Task-Validation-Exit (ETVX). Regardless of what one uses, be aware that what is supposed to go into a process and what is supposed to come out of it need to be clearly defined using criteria that can be measured (cycle time, defect thresholds, system availability, actual vs. planned, etc.).
5. Phasing - don't try to do everything at once. Understand what can be done in parallel, what activities are dependent upon others, and how the activity will affect surrounding systems or business processes. The more complex the undertaking, the stronger are your reasons for doing it in phases. This is especially true when you're tyring to implement a new or changed process or procedure because people, by their nature, resist change. Figure out what needs to be done first or what will get it moving in the right direction and implement that first.
6. Sign-off and acceptance - ensure that any deliverable is both accepted and signed for as accepted. In projects this includes change orders, each deliverable as it is turned over, and the final project close-out. For production systems any change needs to be approved in writing before the change is made, and accepted as successful in writing after the change has been effected. For issue management, this includes sign-off by the person who initiated the issue. And the list goes on...
7. Communicate... communicate... communicate - know who the stakeholders are and make sure they know what's going on. This takes the form of status reports in projects, updates to issues in issue management and permission to proceed in change management. It also extends to team members who need to know what's in that statement of work (as well as have input into it when it's being drafted), and anyone else who pays for, has a role in or is affected by whatever it is that you're doing. In service level management communications is also handled by publishing statistics that show how well you did in meeting objectives. When everyone knows what's expected, what's happening (and why) and the goals and objectives, things like teamwork and high morale start occuring.

There are common functions and activities, such as risk management, service and support, and reliability that should occur in each of the above items. However, the bottom line is the seven items listed are the essentials that need to be in place. None of them need be complicated, and none of them will hamper flexibility and agility. However, the absence of any or all of them will result in problems ranging from total chaos to inefficiently run projects and teams.

Friday, January 25, 2002

 
Posted by Mike Tarrani 5:13 AM

Maxims

I'm in a soapbox mood at this late (or early, depending on your perspective) hour. Left unchecked I tend to write missives, but sometimes a few words have as much power as a few paragraphs, especially when the words are to plant thoughts and restate those obvious facts that we sometimes lose sight of in our daily grind. Hence, the following potpourri of maxims--rules born of lessons learned and experience--addressing topics in no particular order.

Project Management

• A task without an associated deliverable adds no value to a project.
• If you don't start your project planning with a work breakdown structure you'll have to eventually develop one in order to rescue the project.
• If you're 15% into a project and you're already 15% off your schedule or cost baseline you will not recover (I wish I could remember the source of this one, but I can assure you that it's true).

Service Level Management

• Never allow a change to be made to a production system without sign-off by the business process owner(s) for whom the system is designed to support.
• Do not close out trouble reports until the individual who submitted the report agrees that the problem has been successfully resolved. The issue can be marked as completed and awaiting sign-off, but never closed.
• Systems are owned by the business, not by IT. We're the stewards and keepers of the system, not the owners. Business process owners have the final say with respect to maintenance windows, changes to the system and should have the authority to waive procedures, such as testing, if business imperatives so dictate. IT is responsible for explaining the risks of bypassing procedures on a case-by-case basis, but the business process owners should have the right to decide their own fate (in writing, of course).

Policy, Process and Procedure

• Policies that cannot be enforced should not be created.
• Any IT policy should:
  1. be traceable to business goals or imperatives
  2. be developed as a collaboration between IT and the business
  3. have executive sponsorship at the company officer level
• Policies govern processes, processes are performed by procedures.
• Processes should have clearly defined entry and exit criteria.
• Always include a checkpoint or validation step in a process model. Example process models include Plan-Do-Check-Act (PDCA) and Entry-Task-Validate-Exit (ETVX).

If you have a maxim to contribute please send it to us and we'll share it here (giving you due credit, of course).

Thursday, January 24, 2002

 
Posted by Mike Tarrani 3:32 AM
So much for parting thoughts for the day. Sleep isn't coming easily tonight. What does come easily is recounting horror stories. To be honest, exposés and climbing on a soapbox are fun. However, they can be so much fun that they become counter-productive. Today I want to share resources that are about IT failures and how to avoid them. This will provide a balanced view of the problems we have and address the reason for the revolution, which is to cast off the poor practices and turn IT into what it's supposed to be.

Let's start with the basics, which begins with the often cited, but little-read CHAOS Report, which was first published by the Standish Group in 1994. This report has greatly influenced the IT project management community. Since you cannot avoid reading about this report, you should read it, heed it, quote from it often, cite it and wave it around in meetings. You'll become one of the annointed ones and will earn a merit badge towards becoming an alpha geek. More importantly, you'll be armed with knowledge that will make you a better project manager.

Another paper I think should be read before getting too deep into changing IT is The taming of the IT shrew - Delivering benefits from IT. The author of this frank look at IT's shortcomings is Dan Remenyi, who is one of my favorite authors. Remenyi's The Effective Measurement and Management of IT Costs and Benefits is one of the best books on the subject, and I also regard IT Investment: Making a Business Case and Achieving Maximum Value From Information Systems: A Process Approach as essential reading for anyone who takes IT management seriously.

Other articles and resources that will provide ideas and show the way to making IT business-centric include:

• The Failure of IT-enabled Change: A technological frame analysis
• Business and IT in Harmony: Enablers and Inhibitors to Alignment
• A better way of thinking about information technology
• The following Gartner Interactive Briefs:
  1. Four Foundation Elements for IT Measurement Success
  2. Five Steps for Aligning IT with the Business
  3. Roundtable Findings on IT Alignment and Effectiveness
  4. IT Spending Levels: Keep Them in Context
• Business as usual

I threw these in because they impart valuable lessons about the business value of IT or otherwise fit the theme of this entry: 5 "T"s of database availability. Yes, this probably belongs in an entry in Notes from the Field, but I'm including it here because it fits. IT Baseline Protection - the Basis for IT Security is another link that fits because we tend to forget about security when we plan and execute projects, which leaves holes and vulnerabilities in the tools and services that we provide to the business.

Taking TCO to the Classroom will clarify the concept of total cost of ownership, which is important because we tend to go charging off to purchase or implement systems without a thought about value and benefit. Never lose sight of the fact that one of our mandates is to protect shareholder value, not squander it. A final resource, Starting a Technology Project, is aimed at non-profit organizations. Given the abysmal record of IT in starting technology projects this is a worthwhile read. Actually, IT doesn't have a problem with starting technology projects--it's finishing them that seems to be the challenge.

 
Posted by Mike Tarrani 1:42 AM
A parting thought before calling it a day:

Nothing so concentrates a man's mind as knowing he'll be hanged in the morning. The prospect of that sudden and imminent departure, when the trap door is kicked out and the plummet into the unknown begins, clarifies what is really important.
- Samuel Johnson

By the same token, nothing so concentrates the mind of a CIO or IT director as knowing tenure or compensation is directly tied to user satisfaction.

 
Posted by Mike Tarrani 12:17 AM
If I had to point to a single root cause of the traditional problems between IT and the business it would be: IT too often works in a vacuum. What I mean by this is we tend to initiate projects with little understanding of how the business we are charged with supporting operates, and we only cut the business process owners and their people in after we're well into the project.

I was involved in two such projects during the past two years that illustrate this:

1. Project 1: The project objective was to develop service level agreements for an international company. The client would not allow any contact with business process owners or end users during the project. The project was doomed from the beginning, and after the first service level agreements were developed it was painfully apparent that:
   • there was no connection between what IT was promising and what the end users needed
   • the service level agreements addressed technical issues and did so in a language that one could not expect a business person to understand - I had a hard time understanding what was being promised, so I know that someone without my 25 years of IT experience was going to be bewildered
   • none of the consultants or the sponsor's people working with them had any clear idea of importance to the business of each application for which an SLA was created
   The client mercifully performed euthanasia on the project.
2. Project 2: I was the lead on this one and the objective was to develop service level management processes for a large Middle Eastern corporation. I came into the project six months after it had been initiated, but the service level management piece had not started. Although I've spend my life roaming all over the world, particularly throughout Asia, this was my first time in the Middle East. I quickly learned the basics of the culture, and had a fundmental fact validated: regardless of the human cultural differences it's the company culture that matters. Moreover, it matters little in which country you're working, or the internal politics and unique culture of any company, IT remains IT. In other words, end users and business processes are secondary to technology. The challenge was to convince the decision makers that I could not possibly develop a service level management strategy unless I was allowed to interview business process owners. This request was finally granted and the resulting deliverables and recommendations were aligned to the business. That it took as long as it did to convince the project sponsors does not reflect poorly on the company's IT management as much as IT the world over. As an aside, I had a great deal of assistance from company employees who were overseeing our performance on the project and also discovered some existing best practices in service level management that had been implemented long before I arrived. There's hope for IT yet.

The moral of this is that no IT project, and especially any service level management initiative, should proceed without first discovering what the business and the rank and file users of the systems and tools we're supposed to be providing need. These needs, a.k.a. requirements, must be known and understood. Also, we exist to serve the business, not the other way around. Remember, we're the revolutionaries who are going to wage war against IT arrogance, and that's how we want the those whom we serve to see us - as enlightened members of a service organization who are revolutionizing the meaning of service and support, and not as elitist technocrats who don't understand why we exist and whose attitudes are revolting.

Wednesday, January 23, 2002

 
Posted by Mike Tarrani 12:33 AM
As promised, a real-life story with names omitted to protect confidentiality:
Background

The consulting engagement was to meet client requirements for software configuration management. They wanted two sets of deliverables

1. Assistance in selecting the best SCM package for their organization
2. Processes and procedures for SCM

The project was not sponsored by the development manager, nor was the development manager enthusiastic about SCM. I was able to get development of change control policies, processes and procedures included in the statement of work.

Results

The following occured:

• The SCM project was scrapped. This came as no surprise for two reasons: (1) the sponsor had no control over development, so had no hope of implementing processes and tools to support those processes without the full support of the manager in charge of development (not to mention the developers themselves), and (2) the process didn't make sense for an organization that was squarely at CMM level 1.
• The change control policies, processes and procedures were delivered to the client. However, the sponsor did not appear to have either the initiative, power or leadership abilities (pick one or more reasons) to implement it. Since the sponsor was responsible for issue management and tier-1 support, integrating change control would have been a nice evolutionary step torwards process maturity.

Lessons Learned

1. Do not undertake a project for a client that you know is doomed to failure. This seems obvious enough, but it's done all the time. A former boss, Don Holman, who is one of the top operational process engineers in IT consulting, once stated that "consultants have to draw the line and refuse to be a party to malicious compliance." I like that term, malicious compliance, because it's exactly what we did to the client. As consultants we should consult, which means being forthright in our opinions of ideas and initiatives hatched by well-meaning clients who have budgets that are larger than the big picture that they sometimes miss. It's our responsibility to say no to half-baked ideas. And some of the goals of this project were half-baked indeed:
   • sponsor didn't have any control over areas or resources critical to the SCM portion of the project's success
   • lack of commitment to change control processes, which was probably due to a lack of appreciation for just how critical those processes were to issue management and RAS (reliability, availability and support)
   • no executive sponsorship - the project sponsor was a mid-level manager in a politically-charged organization
2. Never attempt to implement a tool until a process is in place. A fool with a tool is still a fool.

Tomorrow I'll dredge up another episode from the past and share it in the hope that someone will be able to use it to bludgeon the pointy-heads out there into submission.

Tuesday, January 22, 2002

 
Posted by Mike Tarrani 1:34 AM
I'll apologize in advance for this, but I just couldn't resist sharing Robert X. Cringely's article titled Trust me, I'm From Microsoft. There are two reasons why I'm sharing this: (1) I'm winding down from a boring day, and (2) the article rings true. Tomorrow I plan to post a few entries that have nothing to do with Microsoft, vendors in general or products. On the contrary, my rants will be on a topic closer to home - the real life episodes of IT in action and the things I've witnessed (and, to be honest, participated in) that highlight some of the errors of our ways. Of course, I'll also give my opinions about how to remedy some of the more glaring IT transgressions. Until then I'm signing off from [now] chilly Tustin, California and headed to bed.

Monday, January 21, 2002

 
Posted by Mike Tarrani 8:15 PM
Humor? Well, the article from CIO Magazine's 1 January 2002 issue titled, How to Run a Microsoft-Free Shop is a little tongue-in-cheek, but wrapped in the humor is a realistic path out of the madness (some would say darkness) that emanates from Redmond.

Yeah, I know I promised that this weblog would not be an anti-Microsoft soapbox, but it isn't going to ignore Microsoft's actions either.

 
Posted by Mike Tarrani 6:23 PM
My first rant in this weblog is going to be a quote from Shane McChesney in Why I Read Joel Spolsky who, in turn, was directly quoting from Joel's Fire And Motion essay:

The companies who stumble are the ones who spend too much time reading tea leaves to figure out the future direction of Microsoft. People get worried about .NET and decide to rewrite their whole architecture for .NET because they think they have to. Microsoft is shooting at you, and it's just cover fire so that they can move forward and you can't, because this is how the game is played, Bubby.

In Joel's essay he goes on to say,

Are you going to support Hailstorm? SOAP? RDF? Are you supporting it because your customers need it, or because someone is firing at you and you feel like you have to respond? The sales teams of the big companies understand cover fire. They go into their customers and say, "OK, you don't have to buy from us. Buy from the best vendor. But make sure that you get a product that supports (XML / SOAP / CDE / J2EE) because otherwise you'll be Locked In The Trunk." Then when the little companies try to sell into that account, all they hear is obedient CTOs parrotting "Do you have J2EE?" And they have to waste all their time building in J2EE even if it doesn't really make any sales, and gives them no opportunity to distinguish themselves. It's a checkbox feature -- you do it because you need the checkbox saying you have it, but nobody will use it or needs it. And it's cover fire.

Lest you think this weblog is going to be a soapbox from which I'll lambast Microsoft, let me point out that Joel's comments are equally applicable to Sun, Compaq, or any other big company with a savvy sales and marketing team. The whole point is don't be a lemming or a sheep. Think beyond the hype.

A parting thought is a joke I once heard: What's the difference between a software or computer sales rep and a used car salesman? The used car salesman knows he's lying.

 
Posted by Mike Tarrani 3:47 PM
What this weblog is about:

We started this weblog to chronicle the:

• disconnect between IT and the business processes that IT exists to support
• internal fingerpointing that goes on within IT and makes us look like idiots to the business units we're supposed to be empowering with our solutions
• games that consultants play

As IT professionals and consultants, our objective is to hold up that mirror and take a good look. Because we care about our profession we are going to also report best practices, lessons learned and anything else we can find, devise or use to make the image that looks back from the mirror a face that we'd like to have others see - a reflection of excellence and professionalism. We'll also see it in the faces of those who we support.

Hence, the title of this weblog, Postcards from the Revolution - we're in the midst of a growing revolution to do the right things the right way for the right reasons. If you are in IT or engaged in IT consulting for a living you should bear in mind that there are no sidelines - you're either a part of the solution or you're a part of the problem ... and problems usually get outsourced (i.e., become unemployed).