11.1 LAYING THE FOUNDATIONS

 < Day Day Up > 



11.1 LAYING THE FOUNDATIONS

11.1.1 Select the Implementation Champion and Group Coordinators

During the design stage you targeted a particular individual who will act as the champion, sponsor or even the customer authority for the implementation of Software Metrics within your organization. If you have not already done so, you should now obtain that individual's agreement to act in that role.

The more senior this person, the better — although you should realize that simply because a manager says something will be so does not necessarily mean that it will be. A high-ranking, involved champion makes life easier in that others in the organization perceive that the initiative has weight. However, attempting to implement a Software Metrics program through this kind of "authority by association" will not be enough. Successful metrics initiatives succeed because the customers of that initiative perceive benefits from involvement, not through begrudged compliance.

There is an interesting phenomena that comes into play when you start to implement initiatives that are intended to change the organization. Whatever rank the person is who supplies the VISIBLE authority for the initiative, the most active collaboration will likely come from individuals one rank lower. The degree of collaboration decreases the lower down the power pyramid you move and, more importantly, the degree of resistance increases dramatically the further up the pyramid you go.

In other words, if the Senior Executive Officer, SEO, or managing director champions the initiative, then board members will be, for the most part, cooperative. By the time you get to the project managers and engineers you start to run into cynicism, and arguments that this is yet more bureaucracy and simple inertia. You can overcome this problem by listening to what the more junior members of the organization have to say, by giving them solutions to their problems and, in a practical sense, ensuring that you have a good spread of seniority within your own development and implementation team. The spread of seniority within the MCG also becomes important.

This scenario is the easiest to work with because you, as the person responsible for making sure that the initiative happens and delivers results, will probably be quite senior within the organization anyway. After all, if the SEO is championing something he or she is unlikely to give that responsibility to a junior member of staff.

More difficult is the situation where the champion is somewhere in the middle of the pecking order. In this case, the person responsible for developing and implementing the initiative will probably be equivalent to a project manager. Because of some psychological effect that seems to come into play, that individual will operate effectively within their own peer group and will have little trouble convincing other project managers that, for example, metrics are a good thing.

The problem is that project managers seldom have the responsibility they should have when you think of the burden they may have to carry if things go wrong. For example, few project managers within the IT industry have true responsibility for their own project budget. Indeed, many do not even know what that budget is! Training is funded centrally as is capital investment. Staff head counts are allocated to the manager rather than being controlled by him. This means that, even when you have convinced the project manager that your proposals are sound, you have to spend time and effort convincing one, two or even more levels of higher management that even a small investment, perhaps in effort, is worthwhile. As you go up the tree, the amount of effort necessary to convince people grows. In simple terms, we seem to be suffering from a form of the "not-invented-here" syndrome again.

There is no easy way around this. You need to put the effort in but you should also start to play "personalities." Identify the senior managers who are willing to listen to you, who are more open to argument and who are at least willing to give your program a chance. Be prepared to tailor your program in the light of their comments and feelings while still retaining the integrity of your program. Do not waste time on the managers who are set totally against you. Finally, get yourself on an influencing skills training course and apply what you learn! After all, every little bit helps.

The worst case occurs when the champion of the initiative is a project manager with limited authority. The approach to metrication I have described so far will not work in this scenario. The organization lacks the necessary commitment. In this case I can only suggest that the project manager does things in a small way and attempts to build a center of excellence in the team. At the same time, he should try to identify and convince a more senior member of the organization to take up the banner and champion the cause. As King Robert the Bruce I realized after observing a spider spinning a web over and over, "If at first you don't succeed, try, try and try again!"

In some cases, you may be able to defer the formal selection of the implementation champion until the end of the build stage. If you have the commitment of the organization to the Software Metrics program then the actual champion becomes less important. In most cases you should still aim to have his or her commitment and involvement as early as possible.

Do not forget to select your local Coordinators as well as the champion. After all, the local Coordinators are going to be the people on the ground who will be making things happen. You need to be sure that they are the kind of people who can do this.

At the risk of sounding pretentious, there are different types of people in any organization. Some are talkers, others are doers.

Talkers come in many guises: some are traditional managers who pay lip service to change but are really too cynical to believe that an organization can change. Others are "technicians" who will appear to support change but whose stock phrase seems to be "yes, but!"

Doers also come in many forms. The obvious and visible doers are often senior managers who take a completely different view of the business than the view held by conventional managers. They are not willing to operate under the status quo but challenge conventional wisdom at every opportunity. Often they make enemies but are powerful enough to be able to afford to do this. An obvious example of such an individual was Margaret Thatcher: you may not agree with her but she certainly changed things, so many things that we tend to forget that she was the first female Prime Minister in the UK. Quite a change in itself!

Of course, you are unlikely to be able to get a gang of senior "doers" as your local Coordinators but you should aim to get the best people you can. In reality, you may have individuals nominated for you. This can cause problems as someone, somewhere will probably use this as an opportunity to get rid of some deadwood.

Try to retain some power of veto. If you have any doubts about your ability to select good staff, keep in mind that this is a skill that comes with experience and depends on the knack of reading people, so get the assistance of someone who demonstrates skills in this area.

The centralized support group, the involved commitment of an implementation customer authority or champion and the group coordinators form the core of your metrics initiative. The importance of these individuals cannot be overemphasized. Time spent making sure that you have the right people will pay dividends. Get this wrong and you will be storing up future problems.

11.1.2 Launch Planning and Pre-Launch Publicity

Hopefully, you have been maintaining an awareness of the metrics initiative within the organization as you have gone through the previous development stages. Perhaps you have used in-house publications or staged presentations to interested groups. Regardless of what vehicle you have used for your publicity, you will need to ramp things up as you move towards implementation. This is especially true if your first phase includes something that affects the whole organization. For example, if your organization has never used a formal defect tracking system or fault database and if this is something you will be implementing then you should be telling the organization why, what and when this will be happening.

I saw a good example of this in a large telecommunications equipment supplier that decided to adopt the Xerox technique of "Competitive Benchmarking." One of the individuals involved in this wrote many articles for in house magazines and took every opportunity to talk to managers about this new idea. Indeed, at one point it seemed as if you could not pick up an in house journal without seeing something about Competitive Benchmarking in it. Also, it seemed as if everyone in the organization had heard of this individual's name and could link it to the technique. As a result, most everyone in the organization believed that it had adopted benchmarking, it was doing things with it, it was going to get results and it was ready to use those results. This was before the project had even gone beyond the pilot stage!

Of course, all this could have slid slowly to oblivion if there had been nothing more. Fortunately, the publicity was only a precursor to a full launch of Competitive Benchmarking and the same is true for the metrics initiative. You need some form of launch for your program and this should be an event.

It can be as simple as a statement by the Systems Development Director that Software Metrics is now an initiative supported by the organization, a part of the development strategy; or, it can be as complex as a road show. Whatever you choose as the launch vehicle you should aim for visibility within the organization.

An excellent method of getting this visibility is the Management Workshop or off-site meeting. We have discussed this earlier but now is the time it really comes into its own. Such a workshop takes a high-level of commitment by the organization but is very effective. To get this commitment you may have to take the plan for the launch forward as part of your program design. Essentially, you take as many senior managers as you can get off the battlefield and into a room for a day or two. Ideally, this room is off-site, possibly in a hotel or conference facility.

Once you have them, you take them through a guided tour of their problems and you present them with potential solutions to those problems. This only works when you get them involved in the proceedings so it must operate as a workshop, not simply as a series of presentations by the metrics team. In fact, the metrics team representatives will talk less and less as the event proceeds. The advantages of this approach are that it gets management involved, it confirms problems and it identifies the players who are ready to try solving those problems.

It also identifies the recalcitrant managers who may cause problems later but it also gives those individuals a chance to shift their stance in a face-saving manner as they are discussing things with their peers, not with some external expert who thinks he knows their job better than they do.

Try not to waste effort unless you are confident of a payback, and in some organizations it would take so much effort to organize a Management Workshop, or you may lack the leverage to make such an event a success, that it is simply not worth it. You must judge for yourself. The program launch can help you with implementation. It should be used to its greatest advantage but remember it is only one small step along the road to success. If the statement of intent is enough for you or all that you feel your organization is ready for then go for that.

After the launch you must make things work so target where you will do this first. This is important unless your first phase concerns the whole of the organization. In that case then your target is predefined, but in most cases the first phase of the metrics program is more akin to a large pilot exercise. By this I mean that you will be putting techniques and practices in place on a finite number of development, support or testing teams. Choose the first teams well!

Throughout development of the program you have been interacting with the organization. You will have identified groups and individuals who are keen to see the initiative succeed and you should use these as the foundation of your program. The chances are that your first phase will not affect such a large segment of the organization that you have to work with the less keen elements.

A model that I find quite useful is the 'rolling wave.' As shown in Figure 11.2, this highlights who should be targeted at any given time. As time goes on, the target changes.

click to expand
Figure 11.2: Targets

Getting the right groups involved first means that you can use success there to convince the more skeptical groups within the organization to join you. Of course, if your initial groups are keen to see the metrics initiative succeed, then they are more likely to demonstrate that success.

A great deal can be said about the types of team you should select for the firsts phase. Should you go for teams working on small projects or large? Should you concentrate on high profile products, or the less important ones? Should you only look at teams who are already using new design techniques? If you go for small projects you have less communication overheads and probably a quicker payback; high-profile projects tend to give you more publicity but there is a risk that they could be cancelled as they could be considered speculative ventures; new design techniques tend to lend themselves to metrication, but how far have they penetrated the organization?

Basically it all depends. What it depends on most are the people involved. There will be problems associated with any project you target, but if the team members are keen to see metrics work they will overcome most of those problems.

Whatever criterion you use you should be very clear where your program is going before you start implementation. Target the teams you want to see on board but remember that you may not achieve 100% success. Target a few more than you want for your first phase so that you have a fallback position, then go for a 100% hit rate on your first choice.

11.1.3 Build the Program Components

What you have to do to build the components of your metrics program will obviously depend on the requirements that have been placed on that program.

For some the first phase will consist of nothing more than, say, productivity measurement being introduced to your software development function. This may sound simple but it can entail the introduction of a project sizing technique, maybe Lines of Code counters added to compilers or the use of Function Point Analysis, and a mechanism to capture project cost or effort.

For others the program may consist of a number of discrete components possibly covering cost estimation, project control, the use of Applied Design Metrics and a range of management statistics.

Whatever the program consists of there will be similarities in what has to be produced to enable the effective introduction of the various components.

11.1.4 Document Techniques

You will almost certainly have to document your design solutions for each high-level requirement in the form of a standard, a set of guidelines or a code of practice.

Such a document is a technical paper and producing these in a way that ensures that they are usable and workable, rather than producing something that sits on a shelf pristine and untouched by human hand, is a skill which takes time to acquire. Of course you may not have the time to acquire that skill so any assistance that is offered by technical writing functions in the organization should be used. Alternatively, rigorous review procedures can help to ensure readability.

Standards that are actually used tend to be concise, readable and coherent. In other words: keep it short, keep it simple or as simple as possible, and keep to the point.

It is a good idea to adopt a style for standards contained within the metrics program. You will find that spending time planning the general layout of standards will pay dividends in the future. Of course, there may be an in-house standard for standards that is already used within your organization and it would be foolish to make enemies by ignoring this. However, you will probably find that standing instructions like this concentrate more on detail than on basic structure. For example, your document standard may insist on a scope statement, an introduction, a document body with rules for numbering sections, sub-sections and paragraphs, and a summary. It is doubtful that such a standard will insist on a three-page scope statement followed by a five-page introduction. If you can get away with one line in each of these sections, then fine! After all, your potential readers are after the meat of what you have to say rather than the waffle one often finds in standards, be they internal or external.

Talk about the style of your documents with your customer authority and the Metrics Coordination Group. They should review any standards that you produce, so get them involved from the start. Using a general style means that your documents develop an identity. It also means that your potential readers get used to your style and can find their way around documents more easily.

When it comes to actually writing then all you can do is get your head down and get on with it, but there are some things to bear in mind. Most important is the 'KISS squared rule:' Keep it Simple, Stupid and Keep it Short, Stupid! I make no apologies for saying this yet again because it is so important that these rules are followed.

There are some traps that it is very easy to fall into when writing technical documents such as standards. I know because I have fallen into most of them at some point!

The first problem is akin to the personality change that comes over some people when they get behind the wheel of a car. Give someone a technical document to write and they seem to don a white coat, their hair becomes disheveled, a wild look comes into their eyes; the 'mad professor' in many of us takes over! The result is a document littered with big words, or even worse new words that only the author has ever heard of. Software Metrics papers are very prone to this and most of the words end with "-ity." We have seen maintainability, reliability, enhanceability and even diagnostability! Sometimes this is unavoidable but there is no excuse for much of the jargon that litters standards. If you do have to use unusual words or words that your audience may be unfamiliar with, then please make sure that you define what you mean, preferably both in the text and in a glossary.

Another problem with descriptive standards stems from the authors familiarity with the subject matter. When the first few chapters of this book went for review a comment that came back from more than one reviewer was that assumptions were being made about the readers familiarity with the subject of Software Metrics. These comments were valid and to counter this problem chapters were added to the book. This does illustrate that even the KISS squared rule needs to be applied with care. When we say Keep it Simple we actually mean 'Keep it as Short as Possible.'

A useful way of tackling this problem is to blend two styles in a single document. If you are describing a measure, say productivity, you can start with a brief, tight technical description of that measure. What is it intended to do? How is it defined? What raw data is required? How should results be presented? This can be followed by an elaboration of the main points that is more chatty, relaxed and that assumes no prior knowledge. If you are describing the presentation of productivity data you may concisely describe this by saying "productivity values will be plotted over time with an associated three-point rolling average." There is no harm in describing what is meant by a "three-point rolling average" as part of the elaboration.

Supplying too much information can also be a problem. Assume that you are writing a standard to describe how your organization will use Function Point Analysis. Does your reader really need to know that they were devised by Alan Albrecht a good many years ago, that there are some nineteen variations available and do they really need even a brief description of all nineteen variants? This is a very easy trap to fall into. After all, you have spent time and a considerable amount of effort digging up all this information. You needed it to be able to make a reasoned set of recommendations to your organization. You want the organization to be aware of all your good work. Believe me, your organization will be much more appreciative if you get in something that works and if you are able to make it work inside your organization than if you continually blow your own trumpet by telling them things they do not need to know.

Also remember the old saw about pictures: a picture is worth a thousand words. In reality some people prefer text but others prefer pictures. You do not know the leaning of a particular reader so whenever possible use both. KISS certainly applies to pictures. There is little merit in producing one complex picture when two, or even three, would do the same job. In fact two or three may work where one fails due to over-complication.

One final piece of advice: most organizations or sites have someone on staff who is a good technical writer. You can find such people by asking around. Who has written decent standards? Have any of your colleagues written articles on effective writing? If you can find such a person, try getting their comments on your first attempts. Then listen to what they have to say and act on their comments.

The standards that you produce are the public face of your program. Personally, I believe that even the best standards in the world are liable to be underutilized unless they are actively supported. People work best when they have a good relationship with other people and you must be prepared to support your customers when they first start to apply the techniques you recommend. It is very tempting to believe that you will be able to do this on the hoof, that is, to make it up as you go along. Forget it! If you are to offer a professional support service to your potential metrics users than you need to think about how you will do that.

This support can take many forms but one example is outlined below. If you are introducing a set of management statistics to a development team then you may feel it necessary to model their development process first. This would seem to be a sensible approach. How will you do this? Perhaps you will apply some basic systems analysis skills to the problem, gathering information through interviews with individuals involved in the process. You need to plan those interviews. How will you start things off? How will you get your colleague talking about their work honestly and openly? Plan your strategy, be prepared, be flexible but use your plan to get what you need from the interview. Document your approach so that more junior team members can benefit from your experience and as you learn from experience update your strategy.

This approach of planning before the event should be used whenever you interact with other people within the metrics initiative. Of course you will suffer relapses. You will go in unprepared to a meeting or you will keep your plans to yourself, but aim to document your plans and you will start to build a permanent foundation for the future and you will develop a professional public image. Eventually it will become part of your makeup: you will be increasingly professional. Then you should take time out, every now and then, to examine the way you are interacting with people to see if you can make it even better. You are going to be preaching continuous improvement. "Practice what you preach" is always good advice!

11.1.5 Prepare Training Material

You are introducing new concepts and techniques to the business. You will have to provide training in both the concepts and the techniques.

Many of the rules that apply to the production of standards also apply to the production of training courses. Tell your audience what they need to know, sell them the ideas, involve them in the course through the use of worked examples and exercises and, finally, delegate the responsibility for action to them. A good training course does all of these things and depends so much on the skill of the presenter that it is sometimes frightening to think about the responsibility that you take on when you first stand up to welcome the group of attendees — frightening until you realize that most people are there because they want to learn, they are open-minded, they want to enjoy themselves and are willing to get involved, they want to leave the course and apply what they have learned to make things better.

Of course there is often one bad apple. Mind you, I usually find that if you give such a person enough rope the other participants will generally hang him.

As always, planning is what makes a course work well. Plan the content, plan the timings, plan the exercises — especially plan the exercises! These are by far the most difficult part of any course to get right. If you make them too simplistic they will be seen as such and be devalued. If you make them realistic they will often be too complex too manage in a course environment. I try to be honest about exercises in courses. Tell the participants that exercises are there to make a particular point more solid, to help understanding and to give them a chance to try things out. Seek their cooperation and you will often find that it is given freely and unstintingly.

Generally, I allow five days' effort to develop one day of training material. For a course on a new subject that I am less familiar with this can double. Budget accordingly.

Do not fall into the trap of thinking that a training course is a concrete entity cast in stone. Training is a two-way exercise and I have never yet presented a course without making changes to it after the event. Some of the best parts of courses I now use have come from ideas given to me by people who have attended previous presentations.

Good training courses are well-planned but they also tend to be given by people who know their subject well. As far as Software Metrics are concerned it is unlikely that a training department will have people who are experienced in the use of measurement techniques within software development. I have always sought to have metrics training presented by members of the metrics team. This approach has worked and I recommend it. Once measurement-based techniques become established within the organization, the responsibility for ongoing training can be passed to the relevant support function. By this time there will be more people available who have experience in using such techniques and who can then present effective training courses.

11.1.6 Build the Metrics Database

You are developing a Software Metrics Program. You will be collecting information, data. It would be a good idea to have somewhere to store this data, facilities to analyze the information, mechanisms to feed back the results of this analysis. You need a metrics database, and preferably a simple one!

Unfortunately you have two problems, well, two major problems anyway. If you look around the marketplace you are unlikely to find a metrics database package that is perfectly suited to your needs although a few vendors do market offerings in this area. You could investigate these offerings and you may well decide that they are suitable for your requirements or that you could tailor them to your needs. The other problem, the more serious, is that you do not know your requirements at this stage.

But, hold on! You have spent a considerable amount of time gathering the requirements for your program, you have designed your program and, surely, the results of these activities give you the requirements for your metrics database. If only it were so.

In an ideal world this would be the case, but you have yet to implement even the first stage of your metrics program. It would be foolish to think that you are not going to gain experience and knowledge from that implementation that could impact upon the structure of your program. The reality is that you have developed a prototype metrics program that you are about to try out for real. It would make sense to adopt a similar strategy for your metrics database.

Of course you can use external offerings as the basis of your prototype database or you may decide to develop it internally. There are many database packages around that are well suited to this approach.

Whichever road you decide to travel, you should treat the development of your metrics database as a sub-project in its own right. What are your requirements as you see them now? Use these to drive your design solution and then implement that solution on your chosen platform.

Be prepared to adapt your database as your program develops. Do not fall into the trap that one organization did: they did sterling work in developing their program right through to implementation and then found that some of their measures were not giving them the information they required. They sought help through a public conference asking the question "what should we do?" The answer was simple but surprised them: "change your measures!" Yes, this implies that they would have to change their database. Is it really worth investing vast sums of money in an all-singing, all-dancing metrics database when fundamental changes may be necessary? Personally, I prefer a cheaper prototype that I can even throw away if necessary.

In the same vein, you may be pressured to build your database within an overall management information system. Perhaps you should tie into existing systems? In theory this makes sense. In fact it makes sense in practice as well, but only as a long-term objective.

At this stage the risk of change is too high unless you have very flexible MIS with a tremendously efficient support team who can respond to very volatile requirements. Management Information technology is still such a young area within software development that most MIS support teams are already completing the equivalent of the labors of Hercules just to satisfy basic requirements. They will not thank you if you hit them with more technical problems where even the problems change radically over time. In this case, time is on your side, so use it.

So, for the first phase I suggest you aim for a prototype metrics database, possibly even on a spreadsheet if your first implementation has a small scope. Build it so that it is of reasonable quality and such that it can be changed as you gain experience and knowledge from your implementation. If you need a politically acceptable face on this approach you can always say that the full database implementation tied to existing systems is planned for phase two, or phase three if you can get away with it.

11.1.7 Build the Data Collection Mechanisms

This is an area worth some discussion in its own right. The way in which you collect this data is important to your program and also depends on the components of your first phase. Data collection is fraught with difficulties but many of these can be overcome by setting reasonable expectations and applying a degree of pragmatic management. Sometimes this is known as using common sense!

Your engineers are employed to develop software, and anything else that they do is considered overhead. These overheads may be very important to the business or to the development of your staff but they all reduce the time that is available for the work that earns the organization revenue, or to carry out the organization's core business. It is sometimes instructive to add up all the time you spend during one week on activities that are not directly related to your primary work objectives. For example, filling in expense claims, non-vocational training, team meetings or briefings, dealing with unsolicited mail from both internal and external sources. All of these things eat into your work week.

Now imagine that you have a metrics program running. Perhaps you ask your engineers to fill in time sheets, to complete defect reports, to fill in project history files. It all takes time!

There is bound to be a reluctance on the part of project managers and others to sanction the imposition of yet more bureaucracy on their staff. You have to accept this and overcome it. Now obviously, you should never suggest that this data be collected just for the sake of it. Data collection should always be associated with benefits even if these are only assumed at this stage. If you have applied the principles outlined in this book so far you will only be suggesting the collection of data to satisfy the requirements of managers for information so they should be less concerned than if you arbitrarily suggest that engineers supply you with elements of information for which there is no clear need.

The guiding principle behind data collection is that it should be nonintrusive. I guarantee that if you investigate the situation you will be amazed at what information is already collected by the organization. Examples of this data can include problem reports, time or effort data, staffing information and financial data including IT spend and, in some cases, return. Of course, this valuable data often disappears into a black hole and is never seen again. Whenever possible you should use these existing mechanisms as the supply source for your data requirements by breaking out of the black-hole syndrome.

There are problems with this approach. Because the data is so seldom used for any obvious purpose the people who have to supply it usually take very little care to supply accurate information. How honest are your timesheets, for example?

You have to be very clear about the validity of your currently corrected data and you need to take steps to reeducate people about the need for accuracy. Often this involves a program of education and close cooperation with the custodians of existing data collection systems. One thing that works in your favor is that these maligned individuals are often only too glad to have someone take an interest in what they are doing and they will move heaven and earth to help you help them.

The other thing that helps you is that engineers would also like to see their efforts being used to benefit the business. If you can convince them that there is a need for timesheets they will often take the necessary care to ensure that you get reasonably accurate information. The thing that has convinced me of this is the number of project teams that I have come across who have additional data collection systems running in parallel with organizational systems. I have lost count of the number of project teams who run a local time recording systems if there is no corporate system. Sometimes they run the local system alongside the company system because the corporate version does not give them what they need.

Why do they do it? Quite simply they see that their own team leader is making use of the information he gets from this extra piece of bureaucracy. A feedback loop is in operation that says, "look, I know it's a pain but the boss is doing something worthwhile with this stuff. Decisions are made based on this information that affect me. I had better make sure that the information is correct or I could get even less time for design, (or coding or testing or training), next time." Self-interest is a great motivator.

Something else that typifies these shadow collection systems is their targeted simplicity. Very often, time recording systems, a convenient whipping horse for this type of discussion, are specified by accountants and have little relevance to the project teams. The shadow systems are designed by the people who need to use the information and this makes them "fit for purpose." They are also invariably simpler than the company system. Simple systems work!

You also need to be very careful about the level of accuracy that you ascribe to even simple systems. Do you measure effort in engineer hours? Do your engineers work a nominal 7.5 hour day? If so you may feel that the timesheet for any day should add up to 7.5 hours. This implies that you expect your engineers to be able to record time to at least half hour precision.

As with many areas, time recording generates jargon and different people use different terms for the same thing. Basically, what you need to do is put a structure on the "stuff" your people do in work, effectively arriving at a Work Breakdown Structure (WBS). I will suggest a WBS that would be suitable for a generic IT department. First, divide the stuff people do into divisions of Work Classes. Suitable Work Classes would be:

  • Project Work to cover software or system development. Remember that if you are working across numerous projects your people should be able to record the Project Identifier within the time recording system.

  • A second class would be System Support to capture the work done in this area. The Project Code would be replaced by a System Identifier. I find it sensible to manage this type of work on an annual basis. Significant enhancements to supported systems or new releases, I recommend managing under the Project Work Class. System Support can also encompass Help Desk Operation.

  • Finally, I would suggest an Administration Class to cover staff management, non-project-specific meetings and all the other "stuff" that organizations need to enable them to work in their core business area. I suggest including a "Leave" Activity to cover absences.

Within Work Classes, work can be broken down into Activities. The Project Class could include Requirements Definition, Design, Build, Test, Implementation and Hand-over. Do not forget the Project Management Activity. If System Support is managed on an annual basis you may simply wish to record effort against Initiation, Execution and Review, and Close-down Activities.

Each Activity can consist of Tasks and it is at this level that staff would record effort against blocks of time. Remember that the KISS rule applies here as everywhere. If you find yourself defining more than about seven Tasks within an Activity you are almost certainly going to too great a level of detail. Of vital importance is to remember two things: you will probably be asking engineers to complete timesheets, albeit electronically, and you do not want this to be overly intrusive or time consuming. Second, if you collect data make sure it is analyzed and fed back to the providers as well as to managers. Even if staff cannot make direct use of the data they can at least see that it is being used constructively.

This approach to time recording is simple, but unless your organization is very mature in the operation of its business (and this has little to do with the age of the company), it is as much as you can reasonably expect.

The one thing about simple solutions is that they generally work, and as soon as people see something that works they tend to try to make it work better. This is perhaps one reason why human beings have developed as we have but the thing about tinkering is that you may end up with things that do not work. This is where a second tier comes in.

On your timesheets you should allow for user-defined fields. This can be as simple as a two digit or character sub-booking code. Of course you need to ensure that your database can sort and total on the sub-booking code.

Some project teams will completely ignore the sub-booking code, which is fine, but others will start to use them for all sorts of interesting purposes.

After a while you can survey the project teams to find out what they are doing, what benefits they are getting and then you adopt the best and start to apply it to the whole organization. The end result is a time recording system that is simple, effective, non-intrusive and one that has been developed by its users.

I have illustrated some of the principles of data collection using the time recording system as an example but the same principles apply to most if not all such systems.



 < Day Day Up > 



Software Metrics. Best Practices for Successful It Management
Software Metrics: Best Practices for Successful IT Management
ISBN: 1931332266
EAN: 2147483647
Year: 2003
Pages: 151
Authors: Paul Goodman

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net