Home 
CM Journal Articles Loving the Evil Twin
CM Journal Articles Loving the Evil Twin
|
I’m in love with an evil twin. And she’s mean. Harsh. Downright cruel. But I love her. I’m crazy about her. Of course, I was in love with her sister first. But there’s no hard feelings between them. In fact, they’re almost inseparable. Her name is Accountability and she’s the evil twin of Quality. I’d like to believe that every person does the best they can, every time, and works toward the goals of the team. But since that particular governing concept drew to a spectacular close back in 1991, we’re stuck looking for a more workable solution for Software Configuration Management (SCM). I’m no “Theory X” management proponent, but there’s no denying that carrots don’t always work. And when projects are in crisis and time is tight, carrots really don’t work without a bit of stick to back them up. And that’s where my true love comes in. Knowing that you will be seen in the bright light of project management or an audit often makes the difference between squeaking it by and doing it right. SCM does not always make individual lives better or easier but it strives to make the project life better and we depend on accountability to make good process work. The core questions of SCM process are based on who does what when, why, and how. A project manager should, at any moment, know who is responsible for moving an item to the next stage. He or she should also know who should be ready to receive that item when it gets there and what will be accomplished. Deviation from the process may make short term sense but rarely improves final product. The functional areas depend on each other. Each of us is accountable to the other functional areas and, of course, the customer. SCM builds change control processes on these principles. Projects burn resources when unexpected things happen and actions often have a ripple effect. And so Development cannot change the product on their own. Testing cannot envision the product differently than what specifications dictate. Requirements professionals cannot write down what the customer doesn’t want. CM cannot deliver the Configuration Item (CI) set it prefers. We develop our processes with the end goal in mind, delivering quality product. And at each step along the way we try to create “handshakes” that identify transitions between events. Our job in SCM is not to manage the project, that’s obviously the PMs job. Our job is to lay out the hampster tubing to get the project from concept to completion so the PM can nudge it along when necessary and monitor the status without sitting on people’s shoulders. Providing clear accountability gives project members the ability to know their own statuses and plan accordingly. If you can show that 80% of the problem reports are sitting in Test for two weeks, it gives the PM both direction and ammo. When those same problem reports are in Test but all landed there in the last 4 hours, clearly Development has some answering to do, not Test. On the positive side, if the project deadline is Monday and the Test Manager can see 50 bugs in the Development stage, they can begin asking for volunteers (or not so volunteers) to come in over the weekend to help the project succeed. From this we can begin to structure the nature of accountability in the process. Picking the right criteria is necessary for each project. I would suggest that the criteria fall in line with the decision that management made on the priorities of the project. What was the order they set on priorities: time, cost, or functionality? From there set your accountability. If they chose functionality, time, and then cost, then the relevant info is identifying what modules are still needed and what have already been done. As SCM, we need to support that system. Instead of waiting for defects or CIs to manage, we should be creating psuedo-defects or issues to track through the lifecycle for each of the expected deliverables. Then the team can use the tool(s), be it a lowly spreadsheet or a state of the art issue tracking system, to keep tabs on what they personally have to deliver and what’s about to land on them. We need to be structuring our tools to help the PM keep tabs on the project and give functional area managers the info they need to govern their own slates. Which brings me to the next point. There is no point in holding a paperweight down on the desk. It does that just fine by iteslf. Use those natural tendencies in structuring the accountability. Go ask the functional area managers what their priorities are. They may or may not be in line with the project. That, in turn, helps you gear the tool(s) toward the projects goals. They may want to know more or less detail than is necessary for the project. For example, like most groups, there are some people who are more gifted than others and tend to handle fires more than the others. A manager may want to know how heavily loaded individual people are. Adjust the tool(s) to give them that flexibility. In a different example, the Dev manager may be juggling twelve projects with 11 people. His or her priority may be another project that’s a personal favorite of the senior VP. While the Dev manager may not be happy with the accountability light shining on him or her, they can use that data for their own benefit. “Hey, I need more resources to do my job and I can show you here why these 4 projects are late.” It provides value to them and further proves the value of good SCM. Once you have identified the needs and priorities of your project team, you can configure the tools. For each action node in the lifecycle, identify who, which team or person, is responsible for completing the task and handing off the deliverable. Below is a very simplified SDLC with the ensuing accountability in the process.  How are requirements generated and approved? Once they are done, how are they communicated to Development? How does Development know the requirement is ready for them to begin coding? Obviously this goes on through the lifecycle but, most importantly, who is responsible for each item? Trigger your action nodes so that users know exactly what they are waiting for and when things are ready. The clearer the accountability, the smoother each transaction is. The following is an example of what might become the lifecycle (and accountability) process based on the Functionality/Time/Cost priority sequence. I’ve kept it simple and it doesn’t even broach the events of the Change Control Board or Software Quality Assurance.
Clearly this is a very basic example but it demonstrates two things. First, while our lifecycle has only four steps, we were at item 6 before it even reached the testing stage. There is much more to flesh out than a four step process. Secondly, it’s clear what is happening in the lifecyle of that requirement. Anyone can look at an item and know to whom to address questions. Orienting the tool around both status and assigned fields gives the PM all the info needed to know if the project is on track. If you have the option of using a tool beyond a spreadsheet, it probably already has some time function built in to use on your second level priority. It probably also records some level of history to changes in field values. This provides the audit trail necessary to show that the team both knows the process and follows it. And if the team is following process, then there are fewer surprises to cost the project. Accountability is also necessary when managing the CI’s. As SCM, we need to define access rights not just to the tool(s), but also to the environments where the CIs are available. It both limits unintended change and makes it easier to track down answers. Many project members initially object to cranking down the access rights but it often proves it’s worth after a short period. With rare exception, all those horror stories of what will happen just don’t materialize. Process is tighter and deviations that cost the project are reduced. One last, but less pleasant, requirement for building accountability into your process is an elevation procedure. This is unpleasant for two reasons. First, no one likes to think that their efforts will be elevated for higher management review. Secondly, it’s often not followed. A simple comment to the PM in the elevator or discussion over lunch with the SQA team lead is something you can’t write out of a process. It’s human nature. But it is important to know where functional areas can take their issues for resolution. Usually it’s the PM’s job to either go-between functional areas or involve the more senior management. But sometimes, they don’t hold the power cards and a different mediator is more relevant. Write up what makes sense. This may mean involving that manager in the tool directly by allowing users to assign an issue to that manager. That’s an opportunity for you. If the only thing the manager gets out of the tool is problems they need to fix, they’ll come to dislike the tool. Lower level project personnel may also see it as an invasion and a way to look over their shoulder. However, you need to show them greater value in the reporting capability of the tool, where everyone benefits. They can structure their workload better because they can see how things are going in the stages before them and how well their deliverables are being received in the stages after them. Management can use it to gain a higher level perspective of how well the project is staying on track. Many project members new to this type of process structure feel that it channels efforts too narrowly and isn’t flexible enough to respond to the “real world.” The simple answer is that the process is as flexible as you make it and accountability makes that easier. Project management goes hand in hand with risk management. If the organization wants the Dev manager to have write access to production, that’s their choice. It’s clearly a bad idea except under the direst circumstances. But you can write process around it that gives it some security and structure to feed changes back into the development lifecycle. Accountability will be blazingly clear as long as the process identifies who can make the decision for Development to be in production. If the Developer did it on his or her own, they assume the accountability. In conclusion, by structuring the process more clearly along the lines of accountability, there is a natural tendency to keep things moving while encouraging quality. I believe that good SCM is like Formula One racing. The machines are pretty equal and every driver can hold the throttle to the floor. It is the judicious use of braking that really wins the race. Too fast and the project crashes and burns. Too slow and you miss the deadlines. Some people fear accountability; others use it as a motivation to perform at a higher level. It is what it is, an evil necessity to achieve good things. I am in love with the twins, Accountability and Quality. They make me look good. 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
Hits: 5135 Trackback(0)Comments (0)
|
| Last Updated on Sunday, 05 August 2007 15:46 |
TrackBack URI for this entry
Subscribe to this comment's feed