Did you forget your: Username / Password ?

Microsoft

TechWell

Home

CM Journal Articles

Taking Territory

Written by Administrator

Tuesday, 15 August 2006 05:12

The enemies of quality are innumerable: expediency, time constraints, laziness, poor design, best intentions, and the list goes on forever. By focusing on two objectives we can build the necessary defenses to protect our organizations from some of this Hydra. There are two primary goals in warfare, business, politics, and CM: control the high ground and control the assets. By effecting both we form a safe cordon which will provide significant gains to the quality of system. Both concepts can be broken down into constituent parts but the result yields clearer authority, greater efficiency, fewer mistakes, and delivers to senior management the control they probably already think they have.

Power is nothing without control
Power is exercised in many ways. Obviously the less effort necessary to control various objectives, the more objectives you can control. We need to initially gain control. As mentioned in the first paragraph, we need to take the high ground and control the assets that make the objectives possible. One obvious corollary is that we need to ensure that once something is under control, it stays under control. Continually having to revisit the task drains organizational resources and taxes any manager and certainly the affected customer.

Taking the High Ground
Let's begin with determining what the high ground and assets are. First, by necessity in CM, high ground is the environments or delivery mechanisms where users have direct access to development efforts. Production is paramount to control and test environments are a close second. Like the big forts that command the narrow passages through which an enemy must go, locking down the production or delivery mechanisms is a minimum required action. Like pulling the goalie from the ice, leaving those areas open to provide "flexibility" is a move only the desperate make and believe to be sound. For every problem that makes its way to the user, we tie up user, help desk, analytical, development, testing, and system admin resources. Clearly this is not a cost effective methodology.

This control also works in reverse to manage upstream points. By controlling the entry points and arena of the high ground, it's much easier to dictate the terms of how we receive items for implementation. Has signoff of system owners and testers been achieved? Are we getting the objects from the correct groups or systems? From a practical standpoint, if we tried to exert the control at the front end, we'd have to fight to improve quality every step along the way. But by starting with the end point, production, and working backward, we simplify the transition for users. If they want to get work off their plate, they know how and when to deliver to the next state.

Asset Management
Assets, different than high ground, can include source code or executables. The core value of technology is to increase efficiency while reducing errors and accelerating delivery of functionality. If we were to calculate how many people it would take to do the work our company does, it would require many times the number of people we have. That staggering loss of efficiency would price our products out of the marketplace and crush the company's ability to compete. Therefore, excluding people, especially for any service-oriented company, technology can easily become the single most valuable asset a company possesses. If it were physically the cash it saves, how would the source code be handled? Access to it would be highly restricted. Changes to how that cash is handled would be severely limited.

Here's a real world example of the value of our source code. If an underwriting system provides 4 people's worth of efficiency and each is paid $20/hr, we are looking at $80 per hour per underwriter. In a good size mortgage business, we could easily be looking at quite a few underwriters. Two hundred people x $20 hr x 4 people's efficiency means our UW system is actually worth $16,000 per hour. That's no chump change. And it's just one of our systems. It doesn't require benefits, nor does it require training to come up to speed or quit at retirement age (without your permission). It is indeed a nearly unparalleled asset.

Banking procedure is a good example of how we need to manage this asset. We're not talking thick mud, slow process. Just clear process that improves accountability. Just like development and testing staff in a software company, many bank branch employees handle the primary asset (cash). Controls have been put in place to identify what cash was dispersed to a given teller, what transactions they have assisted with, and how much cash they returned to the vault at the end of the day. Why would this be any different with systems, again, a company's most valuable asset? We need to track who has code checked out, for what development purpose, and what changes they made when they return it for safekeeping to the version control tool. And like multiple tellers assisting a single customer account, we may have multiple developers making changes to the same set of code.

And banking transactions aren't as complicated as software development. In the end, you just add up the transactions and add up the money. If they tally, you are good. In software development, it's much harder to pull a transaction out and restore the balance. You are often affecting multiple files for a single change and commonly releasing multiple changes so backing one out can seriously impact the remaining. You might be able to account for the remaining changes but it doesn't mean they will work correctly together. We need to set those controls to ensure what we deliver is exactly what was successfully tested. Once you begin relaxing these controls, we lose accountability. And accountability is the evil twin of quality. Lose accountability and you lose efficiency.

In order to begin achieving the dichotomous control necessary, the following activities need to take place: assessment, organization, communication, and logistics.

Scanning the Terrain
What do we produce? What are the assets that need to be controlled? How do we deliver assets to our customers, internal or external? Who should have the authority to initiate changes? What technologies do we own or need to help us control what we have or plan to have? What kinds of communications are necessary to create and support our deliverables?

All of these questions and so many more are geared to the executive focus. Ignoring for the moment the specific functionality we are trying to build, we are looking to construct a mechanism that creates and supports the products and services the business wants to deliver. In doing this, we are providing the flexibility that allows us to scale the organization or shift gears from an unsuccessful product to a more successful one. We need to both create and support as separate efforts. This is very much the difference between taking territory militarily and occupying it. Understand they have very different resource needs and objectives. Creation requires a great deal of design effort, development, and testing time while production support will mean solving narrow and immediate problems without conflicting with continuing development efforts. What kind of response time will the customer expect?   What times of the day/night? We need to understand what expectations we are meeting and what resources are necessary to get there. Once we understand what we are producing, what expectations we are meeting, and what resources we have, we can begin to organize ourselves to meet the objectives.

Taming the Beast
Structural definition is never easy. We're forced to work from many current assumptions which continue to evolve. Ideally the structure we create will be flexible enough to navigate the seemingly drunken path that business asks of us. In defining this structure, we need to determine what the priorities are.

As mentioned in the previous section, for most organizations dependent on the competitive advantage of their software, production/product needs to be the center of the world. Maintaining and protecting that asset should be the first priority for most businesses. Those who own the applications or products within the organization and those responsible for running the servers or release mediums should be, by necessity, mistrustful of changes coming to production. They need to vigorously fight half-hearted or inconsistently tested changes coming into the production domain. They need to know that the code they are implementing is precisely the code that was tested successfully and is accompanied by an implementation plan that ensures proper release. Most importantly, they need to know management supports them in their protective stance. With the cost of failure so high, both in direct down time and potential reputation affects altering future sales, we need to establish roles that enable the company to make the changes needed to stay competitive while adhering to discipline.

Moving on, do we need to organize the structure by product line or by functional area? That might be answered with the duration length of your projects and the clarity with which costs are assessed at every step. Long duration projects and clear cost structures lend themselves to product line organization. Short projects and blurry cost structures would suggest that borrowing project members from functional pools is the more advantageous route.

Having defined the overall structure as project or product oriented, we need to define the necessary expertise. Any development effort needs requirements, design, development, testing, and implementation. That's not to say you need separate individuals performing each of those tasks. Depending on the size of your company, you may need to combine some of those or even break those roles down further. Remember, these activities are required to flow from one activity state to the next. Users will need to know when action is necessary from them and when it's ready to be handed to the next state. Once we figure out what activities you are going to pursue, define the skill sets necessary to complete those tasks. Then you can start matching people to the tasks.

Consider if you are willing, and is it necessary, to release people after a project terminates or is it fiscally better for us to keep the knowledge and experience on staff and avoid frequent ramp up costs? One thing to keep in mind is good auditing technique to separate functional efforts. Putting production admin staff under the development manager is a sure fire way to wind up with conflicts of interest. That's not to say developers are a lot to be mistrusted but when people's reviews are subject to the momentum of a point in time, it can be trouble. The trick is to motivate people in a way that serves the organization, not just at a team level. Putting the brakes on something may make a project manager look bad, but if it prevents greater losses by the organization, then that's where the motivation has to lay.

In this regard our focus should be on identifying the structure we want, not trying to protect against specific threats. If you build a vault with only one door, you only need to worry about one entry point. But if you are trying to defeat a specific technology or threat, you will find the options endless and evolving while your budget is unable to cope with addressing them all. In other words, build the channels that force the flow to move through pre-determined avenues that are easily monitored and controlled. And make it clear who owns an object at a given point in the lifecycle.

One major difficulty in doing this is trapping yourself in existing structure and personalities. You need to look at the world as we want it to be and build toward it. Beyond defining what we need, we'll also need a transition plan to delineate out how we go from what we have to what we want. Some individuals in the organization are inherently more talented, resourceful, or plain harder working than others. We do not want to build the structure around them, as tempting as that may be. They can and will move on leaving us in a position where we may have to reinvent the organization to recover.

A Constant Buzz
A deployed army or business with numerous branches can not be successful unless the units on the ground are able to communicate with each other or the organization will devolve into some level of chaos which is obviously inefficient. Most importantly, communication needs to flow both up and down and also across. Governments and most large organizations continue to operate pretty well despite changes in leadership because individual units know what they are charged with doing and what other areas they need to work with to accomplish those goals. Senior management should be pointing in the right direction but the troops still put one foot in front of the other. Communication is the grunt footwear for organizations. When it's a poor fit, people aren't going far.

Self-service is king. Like ATMs, online shopping, and automated phone systems, the more you can have the users doing for themselves, the faster and more accurate the communication will be. And there are 3 critical factors to consider: centralize the data, make it searchable, and control the who and how of updating. Whether your team uses a sophisticated project management tool, an issue tracking tool, or a blog, make sure it readily conveys the current information, and is accessible to the right people. Even if you have hardworking, assiduous staff, you'll still find people getting off course if they have to expend effort looking for highlights.

Ideally, your communication system will allow you to transition tasks from one group to the next, with the right data. Structure the tool to convey what people need to know to get their job done. Sometimes you can do this at a form level within the tools, other times you might be able to group information appropriately.

This isn't intended to prescribe highly structured silos for your organization. Whether you do NASA level work or are an extremely Agile-focused shop, the core principles of communication are still relevant. The faster you can get accurate information to people in a manner that allows them to run with it, the more efficient your organization will be. It also allows management to watch the flow and stay out of people's hair or step in when problems pop out of the flow.

Consider that the communication from design to development to test will be different than that of a defect being fixed. A quick, flexible organization will need at least two channels for communication across the lifecycle, one for change requests and another for bug fixes. The second will be leaner because it is intended to match existing requirements, rather than getting approvals for change. You may also need to differentiate communication from internal versus external customers.

Marching on Its Stomach
Logistics can be somewhat nebulous. For software development organizations, we're not moving people or physical goods, we're moving code. Who implements the code to your test environments? It should be the server admins, not the development staff. Are you merging code from multiple overseas shops? In that case, a development integrator role would be a strong resource. Give strong consideration to what you are moving and how you will control and protect the asset or high ground.

I personally would consider training to be a logistics effort. Your staff has to be trained in the tools, methodologies, and organizational structure to be highly successful. Your customers should be well trained so they can get the maximum benefit from your products. The training manuals, both internal and external, should be considered part of the assets you manage. For each task at the project team level, consider what's needed to get started, what has to happen, what is being delivered for the next group to pick up the work, and how you can verify that it's happening properly.

Conclusion
Once you have controlled the assets and high ground by the steps outlined above, you can really start to control the quality issues that plague so many places. Quality isn't cheap but we know that failure can be very expensive. You can take a page from politics, business, military strategy, and good CM to wrestle your organization into a better position. The simpler the solutions, the more robust they will be. Stick to the essentials and the work will come out well. As a CM you may not be able to directly influence all the issues discussed but you may be able to nudge them from time to time in a better direction. Extraordinary is only the ordinary done well.

Randy Wagner is a Contributing Editor for CM Crossroads and VP of Technology Development with Taylor Bean & Whitaker in Ocala FL. His experience ranges from major financial institutions to multimedia multinationals to the Federal government. Working in small to large project efforts has given him a unique perspective on balancing the discipline of SCM and enterprise change management with the resources and willpower each organization brings to the table. You can reach Randy by email at SR_71_98@yahoo.com.

Set as favorite

Bookmark

Email this