Saturday, January 26, 2002
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...This prayer, offered nearly 800 years ago, applies to challenges we IT professionals struggle with today.
- Saint Francis of Assisi
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:
Either way, business efficiency and effectiveness, and shareholder value suffer.
- 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
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:
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.
- 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.
- 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.
- 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.
- 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.).
- 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.
- 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...
- 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.