Identifying, gathering, and leveraging the right mix of metrics is a way to gain better control of your large project. The value can be quantified in a number of areas including:

1. Improved performance of the overall project fulfillment and delivery process
2. Improved estimating for future projects
3. Validation of duration, cost, effort and quality objectives for the project
4. Identification and communication of best practices
5. Improved client satisfaction

In general, metrics provide a more factual and quantitative basis for understanding how you are doing and the things that can be done better. Without at least some basic metric information, all discussions on performance and improvement are based on anecdotal evidence, perceptions, and guesses. Collect metrics, even if they are imperfect and imprecise. They still provide a better foundation than recollections, perceptions and guesses.

Collect the metrics you’ll use

You don’t want to collect metrics just for the sake of collecting them. Of course, you need to collect any metrics that are mandatory for your organisation. In addition, you should collect any other metrics that are needed by your particular project. However, if you don’t have a purpose for the metrics, or if your project isn’t long enough that you can really leverage the information, these customised project specific metrics are not worth collecting for your project.

Make sure the value of collecting a metric is worth the cost

Just as there is some cost associated with most project management activities, there’s a cost to collecting and managing a metrics process. Some metrics are interesting, but don’t provide the type of information that can be leveraged for improvement. Some metrics are just prohibitively expensive to collect. The cost to collect each metric must be balanced against the potential benefit that will be gained. Start by gathering metrics that your organisation requires. Then add metrics that have the lowest cost and effort to collect and can provide the highest potential benefit.

Make sure your metrics tell a complete story

The problem with many metrics is that they’re reported in a way that doesn’t tell a complete story. The project manager and project team may know what a given metric is telling them, but other people accessing the information may not.

One way to help is to always report the metric along with the target. For instance, if you report your current expenditures to date, also include your expected expenditures at this point in the project. If you report that your project has spent $100,000 so far and your total budget is $150,000, the reader still doesn’t have the context to know whether this is a good or bad situation. Sure you’re under budget, but the work is not complete either. The better way to report this information is to state that you have spent $100,000 to date and that according to your estimate you should have spent $110,000 at this point in the project. If the trend continued, you estimate the final cost of the project to be $135,000 versus your budget of $150,000. If you report the metrics with this context, your readers can understand what the numbers are saying.

Train your team in the purpose and value of metrics

The general definition of "metrics" is not always obvious. The project manager may be trying to create a metrics program for a large project, while the project team doesn’t make the connection between gathering metrics and the business value received. This disconnect may affect the client as well. The project manager should take the time to explain why metrics are needed and how the information collected will help drive improvements. Likewise, the team should understand how to look for metrics that will provide an indication as to the state of a process or a deliverable. Educating the team and the client will help the project manager obtain better metrics with less work effort and less pushback.

In my post Four things you should know about your technical staff , I talked about some of the general characteristics of an IT project team. For example:

1. They tend to be introverts
2. They tend to think more logically than emotionally
3. They tend to be problem solvers
4. They tend to be technically creative

Knowing some of the characteristics of your technical staff allows you to better understand how to manage them effectively. Applying some or all of the following techniques will help you create a more conducive work environment where people can excel.

Give them the tools that need to do their jobs.

Establish an environment where people feel they have what they need in order to do their jobs. This includes having appropriate hardware and software. It doesn’t necessarily need to be state of the art, but it should be of acceptable quality. Because they’re in the IT field, IT people get frustrated when they don’t have the right hardware and software to do their jobs effectively.

Make sure they have the right skills and provide opportunities to learn.

IT people love to learn new things. Managers should make sure their people have the skills needed to do their jobs and that they receive opportunities to grow into new technical areas. This doesn’t have to be third-party training classes. It can include computer-based training, seminars, webinars, books, magazines, etc. Also, once someone has mastered a certain skill and they start to become bored, look for ways they can cross-train and learn new areas of the group.

Create a viable work environment.

Technical people like to understand the work processes in the group, and then they like to be creative in working within that structure. So, set the high-level rules, but don’t micromanage the details.

Give people as much information as they need to do their jobs.

Managers should strive to be proactive communicators. Remember, many IT people are introverts who like to process information internally. They may or may not come up to you and ask you what’s going on all of the time. Managers should make sure that they communicate as much as they can about what’s going on in the company, their organisation, and their group.

Shield the team from office politics

Don’t let your team get bogged down in the organisation muck. This means removing organisational roadblocks and shielding the team from organisational politics. IT people will tend to get cynical fast if they feel like a political environment is affecting their work or in decisions that affect them.

Make sure each person remembers he’s part of a team.

Even though IT people tend to be introverts, it doesn’t mean they prefer to work alone. IT staff may prefer to work independently, but they also like being a part of the team. Managers should nurture this need. For instance, they should have regular team meetings. Managers should also make sure they have opportunities to do fun stuff as a group - even if it’s just going to lunch together once in a while.

Be there when needed and respond to problems and concerns.

Not all problems can be fixed, but many times the simple act of listening and trying is enough. People will give you credit for trying, even if the ultimate resolution to a problem isn’t available.

You might note that many of these management techniques are not unique to technical staff in general or IT staff in particular, but they’re particularly applicable to the IT staff.

To many people, the focus on diversity is synonymous with the hiring of inferior quality for the sake of meeting quotas. But companies have found that there is long-term business value associated with a diverse workforce. Why is diversity awareness needed to begin with? Let’s assume your project team has an opening. You want to hire the best candidate available, right? In many cases there is a clear "best" candidate based on experience and skill level. However, if there are many such people to choose from, the hiring manager may rate a candidate’s qualifications using his own background as a measuring stick. After all, if a project manager has a certain background and ended up in the position he is in today, wouldn’t it make sense to him to look for those same traits in another person? Wouldn’t he tend to pick a person that physically looks like him as well?

Project managers also want to make sure they hire someone that will get along with the rest of the team. Again, if there are multiple candidates with close qualifications, the project team may choose a candidate who is "more like themselves".

If teams are left on their own, these two sets of natural biases tend to result in a like group of people hiring a similar candidate. In some organisations and on some projects, this results in a bias against workers of the opposite sex. In other businesses, there’s a bias based on culture and race.

Companies, especially large ones, have tried to formalise and standardise the recruiting and hiring process in a way that allows each candidate to be judged based on the same set of criteria. The goal of a standardised process is usually not to hire diverse workers. The goal is to remove as many of the subconscious biases as possible and to ensure that the most qualified candidate is hired.

Diversity awareness lets you:

1. Make better decisions. People from the same types of backgrounds can have a tendency to think alike and this can affect the decisions that people make. Project managers need a diverse set of opinions to make the best technical decisions, to communicate more effectively with all of your clients, and to design and build the most creative solutions.
2. Hire better people. Ultimately there is value in being able to hire the best person, regardless of the person’s background. In many cases, organisations that do not value diversity end up not hiring a group of people that all look and act the same. They will tell you that they are always hiring the "best". But is it really true that the best people all look and act the same as each other?
3. Running better projects. You have to be experienced managing diverse people to excel in today’s global marketplace. Can your project team really develop software that is used around the world, for instance, with an entire team that all comes from the same background? Can a project manager manage a worldwide distributed team if he has never managed people that are different from him? Can you service your diverse customer community effectively without a diverse project team?

The bottom line is that there is value in having a diverse workforce and a diverse project team. If this was an artificial feel-good idea, it would not be so important to so many companies. However, companies have found that valuing diversity results in hiring better people and provides real business benefit.

Building a better bottom line is just as important for an IT department as it is for the whole organisation at the enterprise level.

Implementing sound financial management within an IT framework is broader than simply being more efficient. Many factors are involved: an understanding of the main drivers of IT costs, aligning IT spending plans with overall business strategy, using financial resources efficiently, viewing IT expenditures as investments and having procedures to track their performance, and implementing sound processes for making IT investment decisions.

Estimating what a project will cost is only half the battle; controlling those costs during the project and after delivery is equally critical. In this article, we examine some methods to predict and manage costs, part of a sound basis for overall IT financial management.

1: Control baseline costs

Nondiscretionary money spent maintaining established IT systems is referred to as baseline costs. These are the "grin and bear it" costs, those required just to keep things going. Baseline costs constitute around 70 percent of all IT spending for the average organisation, so this is a good place to start. These costs tend to creep over time due to the addition of new systems, meaning there’s less money available for discretionary project work. Worse yet, this creep gives the appearance that IT costs are rising while the value derived from IT investments stays the same or actually goes down.

Fortunately, baseline costs can be easily controlled. Renegotiate vendor contracts, reexamine service levels, manage assets effectively, consolidate servers, sunset older applications, maintain a solid enterprise architecture, and practice good project and resource management. By so doing you can lower the percentage of the IT budget allocated to baseline costs and keep them in line, avoiding problems with opportunity costs. Think of IT projects as an investment portfolio; the idea is to maximise value and appreciation. Baseline costs are food, clothing, and shelter; we have to spend the money but it doesn’t have to overwhelm the budget.

2: Acknowledge hidden IT spending impacts

Gartner estimates more than 10 percent of corporate technology spending occurs in business units, beyond the control of IT. Several factors contribute to increasing hidden IT spending:

- Flat organisational models more difficult to rein in and control

- Virtual enterprise structures ostensibly set up as nimble, agile organisational constructs but without regard for policy and procedure

- Changing organisational authority where business unit managers are given (or take) responsibility for decentralised technology spending

- Selective IT outsourcing, in which a business unit will independently decide it doesn’t need to participate in overall enterprise architecture to fulfill its departmental mission

The impact of all this hidden technology spending can be profound and prevents IT from being able to control project costs. Architectural pollution from rogue projects can delay change, resulting in cost overruns and lost opportunities. Business unit-sponsored systems eventually become the responsibility of IT, increasing the cost of support and maintenance (there are those baseline costs again). Cultural biases in business units may conflict with overall strategic goals, increasing costs and resulting in the destabilisation of information and knowledge. This is just as important for small companies as well as large; fundamental business decision-making is driven by solid information, and if we don’t have it we can’t do it.

3: Understand long-term application costs

As a general rule, ongoing application costs are about 40 percent to 60 percent of the original development cost for each year in an application’s life cycle. Sound like a lot? These are the costs associated with application support, maintenance, operations, software licenses, infrastructure, and allocated help desk and operational staff. Controlling these ongoing costs is critical; as a component of baseline costs, they’re necessary evils. Collect and maintain information about all new development work underway throughout the entire enterprise and actively participate in all projects as a value-added business partner. Communicate effectively and relentlessly; report to senior management anticipated costs both at the start of projects and at appropriate intervals thereafter. Don’t forget to maintain a historical record of all costs.

4: Understand IT cost estimation truths

How good an estimator of project costs are you? I’m sorry to disappoint you, but no matter how good you think you are, you’re not that good. None of us are; your crystal ball is just as cloudy as anyone else’s. This is the single biggest reason IT projects have such a high failure rate. Remember: the cost of IT initiatives will typically exceed original estimates by an average of 100 percent.

Institutional knowledge is lacking as to the result of major initiatives, the advice and counsel of IT is routinely omitted or ignored, and business process change relies too heavily on IT ownership of those business processes. How often have you been called upon to estimate, if not virtually guarantee, a project cost before the scope has been fully defined?

As an IT professional, whatever your role on a project, you must provide business managers with parameters for setting funding expectations and force those business managers to explain why their assumptions are valid. If you’re an IT manager, track all major development efforts throughout the enterprise and regardless of your role, participate in the creation of a knowledge base of maintenance and support costs to drive future verifiable and credible estimation. Don’t underestimate the future costs of maintenance and support and whatever you do, don’t make the classic cardinal error: do not, under any circumstances, pad budgets in anticipation of an underestimation. Keep track of project costs as the project unfolds and communicate, immediately and vociferously, the instant you detect even the potential for an overrun.

5: Leverage current system investments

Applications, purchased software, networks, infrastructure, and any IT investment should all be regularly reviewed, at least on an annual basis, to ensure maximum value is being extracted and that original ROI goals are being met. Start with the original requirements and review them to ensure return on investment goals were delivered. Examine changes in the business and review new requests to determine whether they fit with the existing systems. Consider business reengineering. Review embedded processes to determine whether they’re consistent with new organisational models and make changes where necessary. Review vendor and product features, making sure they still fit within the organisation. Enterprise architecture is organic; it’s not once and done. It changes over time. Keeping up with those changes allows for adjustments either at the periphery or by making modifications to existing components. This is an effective way to control overall costs.

6: Implement short-term cost cutting measures

Often we can control costs by putting in place tactical solutions. Short-term thinking can also be an effective tool in project cost estimation, in that it focuses us on the details. Getting from New York to Tokyo involves a fairly long flight, but we can’t forget that we still have to figure out how we’re going to get to the airport to begin with.

Try to postpone capital purchases as long as possible. This may not only provide time to negotiate better costs, but an idea for a less expensive solution may present itself after the project has begun. Always control project scope. Come to agreement as quickly as possible with business unit customers and sponsors as to the overall project scope and put that in writing. Have an effective change management process for the inevitable "just one more thing" discussions, which will limit or postpone until after project delivery the single biggest reason for cost overruns.

Try to control human resource spending. There are only two reasons to use external consultants — to fill a knowledge gap (we don’t know how to do something) and to fill a resource gap (we have too few to complete the project on time). Negotiate the best possible rates and where possible, use fixed-price agreements rather than T&M (time and materials).

7: Implement long-term cost cutting measures

Be tactical, but don’t forget to be strategic at the same time. Make sure there’s an enterprise architecture; it’s hard to put the puzzle together when you have no picture on the front of the box to go by. Eliminate duplicate processes and systems, eliminating unnecessary costs in the process. Reprioritise and rejustify all IT projects on a regular basis. Just because something made sense in January doesn’t mean it still does in August, so why waste the budget? And outsource selectively. These are the costs that typically are the most controllable yet too often lead to the highest cost overruns.

8: Implement pricing and chargeback mechanisms

I once worked for a CIO at a Fortune 500 company who decided an internal chargeback process was needed to make business units more accountable for technology costs. He successfully implemented the new approach and was credited with saving the corporation many millions of dollars. He was also fired, because this approach is the one most fraught with political peril.

Absent a chargeback mechanism, business units tend to look upon IT as a giant free toystore. Put one in place and those same business units feel free to go to the outside to get more competitive technology pricing, and IT loses control and becomes marginalised.

If your company is going to consider this, there are ways to achieve both goals: making the business units accountable and maintaining central technology architectural control. Internal IT must be competitive with external service providers. Periodic benchmarking exercises are key. Don’t underestimate the substantial resources needed to effectively administer chargeback mechanisms to ensure that business units have all the information they need and no one feels at a disadvantage. IT must have a clear understanding of all costs and manage the demand appropriately. Use client satisfaction surveys and service level agreements (a good idea no matter what the circumstances) and always show a balance between costs and benefits.

9: Use governance to drive IT investment decisions

Too many organisations fly blind, with little synergy between IT and the business. In most organisations, IT is a discretionary expense center; there’s a fundamental framework (baseline costs again) but most, if not all, of what’s required beyond that isn’t necessarily mission critical.

Enlightened organisations understand that IT is a value-added strategic business partner, and a successful collaboration between IT and the business drives significantly increased stakeholder value. Establish, or if one exists become a participant of, a strategy council to examine enterprise-level issues of strategy, politics, priorities, and funding. Set up a business council to define priorities, oversee projects, and measure (and communicate) project success across business units. This group must, of course, have the courage to cancel projects when that becomes necessary; not everything that starts must finish. Put together a technical council to develop guidelines and principles for technology standards and practices. These are three very different organisational constructs, and while there may be some overlap in terms of participation, the mission of each is mutually exclusive.

10: Quantify the value/benefit proposition for IT investments

Why do we do what we do? That’s not an existential or rhetorical question. IT exists to provide value, to participate in the achievement of organisational strategic goals. How can we prove we’ve done so? Just because we’ve built a thing, that doesn’t mean much. Does the thing work? Does the thing provide value? Is that value measurable and consistent with the corporate mission?

Some quantifiable benefits of IT work can be improved operating efficiencies, enhanced personal productivity, enhanced decision quality, and/or enabling or supporting organisational strategic initiatives. What’s most critical is to ensure the credibility of any measurements used to justify IT investments and provide after-the-fact valuations. You may be working on a project that will reduce a process from five person-days’ worth of work to two. Does that mean three people are going to be fired, with the resulting compensation cost saving attributable to your project? Probably not. Those folks will most likely be reassigned, so don’t take credit for expense reductions that aren’t going to happen.

I recently came across a survey blurb that stated that a certain percentage of management feared being out of the office because they were afraid that a subordinate would outshine them in their absence. While I don’t remember the exact percentage of those respondents, I know it wasn’t a trivial number.

I was a bit shocked by the response because (perhaps naively) the thought never occurs to me when I’m out of the office. The fact that there are managers with this paranoid fear says several things to me about their management difficulties:

1. They are very insecure in their position.
2. They work in a very dog-eat-dog environment.
3. They are afraid of their own subordinates.
4. They probably take credit for everything.
5. They probably never share in the blame.
6. They have low self esteem.
7. They don’t view their marketability as being very high, increasing their fear that they will lose their job.

Perhaps I have it all wrong, and in fact, they are all very well adjusted and particularly shrewd in the analysis of their current situation? Maybe a few, but I’m guessing the rest of the respondents have one or more of the problems described above — all of which are bad and need further elaboration.

First and foremost, no manager can be effective if they truly are afraid of being shown up by their subordinates when they are out of the office. These managers are not likely to mentor their subordinates, don’t give a flip about continuity/succession planning, are probably very risk averse, are very controlling and route every decision to themselves, and probably micromanage to an extreme — in other words — a real dream to work for.

Addressing the first two points, one must wonder if the insecurity is rooted in actual behavior observed in the current environment (have they seen it done to others before in their workplace?); is this a manifestation of past experience or just plain paranoia? If this is a regular practice in your workplace and you don’t happen to be playing for an NFL team where you are fighting for roster spots all the time, then one might consider looking for a healthier environment. If the insecurity is based on other factors, some serious introspection is probably warranted.

Points three, four, and five above are mostly symptoms of their fear, manifested as poor management. Points six and seven are personal problems that need to be dealt with on a case-by-case basis and perhaps some counseling; however, all the traits in the list above can be dealt with proactively in some fashion by changing some workplace behavior.

If you’re afraid of being replaced by a subordinate, you can solidify your position in proactive and healthy ways. The first way is by building better relationships. As a manager, you have readier access to individuals in the organisation that your subordinates do not. Use this access to build relationships with those above you and across from you on the organisation chart. It is not only good for business — you will come to understand the operations of your organisation better — but it also buys you the good will of the people you interact with. Relationships are taken into consideration when hiring, firing, and promotion opportunities present themselves.

Being out of the office (assuming it is for business) also means that you again have opportunities for relationship building and for networking. Good work outside will filter back to your organisation.

If you are concerned because you believe you have lost your edge and your subordinates are sharper than you — do the obvious. Work on sharpening your skills to stay competitive. Keep in mind that the skills you are sharpening are probably not the same as those of the people reporting to you, particularly as you move up the organisation. How well you program in C# probably doesn’t amount to a hill of beans to your boss if your job is not to program but to manage. Lifelong learning helps you to avoid skill gaps that can lead to insecurity and low self esteem.

Try and remember that as a manager you work THROUGH people and they are your assets and hopefully your allies. If your workplace resembles Mutiny on the Bounty, you had better take a hard look at how you are managing. Your subordinates should not hate you nor be plotting against you. If they are, you better try to get to the root of the problem ASAP, and you should start by looking at yourself first.

Lastly, work hard, be proud of what you do, but always be ready to leave. The workplace, as is the world, is a very unpredictable place and hardly ever fair. Never get so settled in a position that you become complacent. Always plan for your next move. Put away some money in an "emergency cache" that can fund six months of unemployment. It may take you awhile to build it, but having it gives you the peace of mind that your world hasn’t completely fallen apart should you find yourself out of work. That peace of mind also works to reduce anxiety about being let go.

In summary, a manager carrying around fears of their subordinates outshining them when they are absent is a problem that needs to be dealt with. Whether you need to leave an unhealthy environment or do some serious self-evaluation and behavior changing, you do not want to operate out of fear. It is unhealthy for the organisation, the people you supervise, and ultimately you, the manager.

Have your ever been paranoid about scheming subordinates or been in an unhealthily competitive environment? Have you ever observed or tried to coach other managers with these traits?