Mind Tree

There are many ways to gather requirements. Interviewing — where you talk to the people who will define the new solution to determine what they need — is probably the default technique for most projects.

Interviewing can be an easy process if the person you’re talking to is organised and logical in their thought process. Since that’s not always the case, however, you have to employ good interviewing techniques in order to start and guide the interview.

There are a number of formal interviewing techniques that will make the requirements gathering process go more smoothly. Here they are.

Start off with general questions.

Typically, you don’t start the discussion by asking narrow, targeted questions. You’ll want to start more high-level and general questions. These questions should be open-ended, in that they require the interviewee to explain or describe something and can’t be answered with a "yes" or a "no". Your goal is to gather as much information as possible with the fewest number of questions.

Ask probing questions.

After you ask general, open-ended questions, you should then start to probe for details. Probing questions are probably the most valuable type of questions, since they tend to result in the detailed requirement statements you’re looking for.

Be persistent.

If you experience any difficulty understanding the interviewee’s point, ask follow-up questions. You can also ask for examples that will illustrate the points the interviewee is making.

Ask direction questions when you need additional information.

Direction questions start to take the discussion in a certain direction. They’re used to provide context and background. For example, "Why is that important to you?" or "Why do you care about that?" are questions that can provide direction.

Ask indirect questions to gain better understanding. Indirect questions are used to follow up on specific points that were raised previously. These questions are used to gain more clarity so that you can ask better questions next. For example, "Is that important because of …" or "You said everything needs to be secure because …"

Ask questions that validate your understanding.

A good interviewing technique is to restate what you just heard back to the interviewee to validate that you understood him/her correctly. For example, after hearing an answer, you could say "If I understand you correctly …"

Paraphrase.

This is similar to the prior technique except that you would take a large amount of information from the receiver and simplify it in your own words. For instance, after hearing the interviewee give a five-minute answer on how a process works today, you could paraphrase the basic points of what he/she said in a quick bulleted list of process steps. For example "So, in other words, the process you use today is basically 1,2,3,4 …"

Ask for examples.

In many (or most) cases of gathering requirements, the interviewer is not totally familiar with all of the information provided by the interviewee. Therefore, one effective way to gain more understanding is to ask for examples. This can also be utilised when the interviewee provides feedback that does not sound totally valid or totally believable. Asking the interviewee for an example helps lend a concrete and specific instance that may help make the requirements clearer. For example, "Can you give me an example of how that affects you?" can help make a statement more clear.

Keep the discussion back on track.

Sometimes the interviewee starts to talk about things that are outside the scope of the specific information you’re trying to gather. This is sometimes caused by a misunderstanding of the question you asked. Other times it’s caused by a lack of focus or a desire to talk about things that are of more interest to the interviewee. When the discussion gets off track, the interviewer must get back on track. An example of this technique would be "That’s a good point. However, can you describe how that relates to (…restate your original question…)?"

Try to stimulate ideas.

Sometimes the interviewee gives the obvious answers but isn’t thinking about other areas that may not be as obvious. The interviewer should try to get the interviewee to stretch a little and think about things that are not quite as obvious. For instance, you can ask "Can you think of a couple options for this situation?" or "Are there other ways to solve this?"

• Leave a comment... (0)

After yet more research into the various species that inhabit this working world of ours, I return with a new set of taxonomic classifications. This time, we concern ourselves with the team leader, in all his or her many guises.

As ever, there are many competent and sociable team leaders in IT departments; but they don’t make for great storytelling. Picking the worst and most dangerous types can help us recognise the signs and maybe even glean a little entertainment from them.

1: Dux Timeris

Fearful Leader

This team leader was persuaded to take the leadership job for two reasons: First, the powers that be decided that there should be a team leader so they could devolve some of their duties to someone who can’t answer back. They picked the least confident team member and tailored the promotion process to ensure that the correct candidate was appointed.

Second, this person was the last to get through the door when the call for volunteers went out. He may have been trampled underfoot in the rush and was slightly concussed when the job offer was made.

Now that this new leader is hooked, he’s too timid to ask to be re-graded and spends a lot of his free time worrying about the job. This is completely unfair, as this type is usually a good person trying to do a good job.

Favourite saying: "Can somebody help me please? Anybody?"

2: Dux Fulvus Nasus

I will leave you to translate the Latin for yourself

This leader does not think for himself but hangs on every word passed down to him from on high. If the boss told him that the sun was inhabited by pixies he would send Christmas cards to them.

He cannot believe what he is hearing when somebody on the team disagrees with a management decision; more worryingly, every critical word uttered within his earshot is reported back directly. Once aware of this, a team can make good use of it for propaganda purposes.

Consider the day of the Christmas party, for instance, when our help desk team was told that it was not permitted to attend. We weren’t expecting any calls, as virtually the whole company was at the bash. We decided, within the hearing of the Dux FN, that we would wait for the party to start and then go home. An hour later, our invite to the party had arrived, with an instruction to switch the phones over to voicemail.

Favourite saying: "I was talking to the boss this morning. Wonderful man!"

3: Dux Magnifica

The Paragon of all the Virtues

This person is under the misapprehension that he has arrived, that he or she is "Look on my works, ye Mighty, and despair!"

Yes, this jerk is full of himself. You would think he had just been appointed World President instead of a glorified tea boy. He took to wearing a pin-striped suit on appointment to the position.

He refers to the senior directors of the company as his colleagues or "fellow members of the management team." He is not a tattle-tale. The views of those under him are far too inconsequential to be listened to, much less acted upon.

Favourite saying: "Follow me lads; I know what I am doing!"

4: Dux Trogloditica

Cave Man

This leader is a technical expert who lives, eats, and breathes computers. He leaves the office at the end of the day and goes home to a techno cave where he spends his off-duty hours making his stock of computers, one that NASA would be proud to own, do things that they were never deigned to do.

When he is not thus engaged, he attends conventions dressed as his favourite character from a variety of science fiction films. D Trog is the first person to talk to about a technical problem and the last person to ask about any leadership or personal hygiene issue.

Favourite saying: "I think you’ll find that James T. Kirk never said, ‘Beam me up Scotty.’ The nearest he got was, ‘Scotty beam me up!’"

5: Dux Dictatorialis

The Dictator

You can say what you like about Dux Dictatorialis, but under him all the calls were logged on time. He (and it usually is a he) is an obnoxious person who can’t understand that people have a life outside of work and wants the world to know that HE is in charge. People who disagree with him usually disappear and are never seen again, although a trip to the media library or any other dark and dusty storage facility may give a clue as to their fate.

The worst thing about any dictatorship is that the weaker members of the team find themselves siding with the bully and become bullies themselves. Fortunately, this species is becoming rare in the wild, as there are many predators and few allies.

Favourite saying: "Come on, get with the program!"

6: Dux Nihilistica

Leader of Nothing and Nobody

D Nihilistica is an unhappy and lonely leader. He was made team leader, but the snag is that his team consists of just one person: himself. He has been doing the same job for a number of years and generally speaking, he does a pretty good job. A year ago, he was surfing a recruitment Web site and was spotted by his boss. They don’t want to lose him, as they would have great trouble in replacing him, especially at the paltry salary they currently offer.

Luckily, they persuaded him to stay by awarding him an upgrade in his status, a move that cost nothing.

Favourite saying: He doesn’t have one; there’s nobody to talk to.

7: Dux Amicus Bonissimus

The Best Mate

The Best Mate wants to please everybody all the time. Nobody ever explained the impossibility of this, so he continues trying, even though experience should tell him that he’s on a hiding to nothing. These leaders are known to go home at night wondering why everybody hates them. This is not true. We don’t hate them, we worry about them. In the futile commotion of trying to be all things to all people, they are in dire peril of going quietly mad.

Promotion is a double-edged sword that cuts both ways. When you are pleasing the bosses, you will upset the team. Stick up for the team and the bosses will blame you for not communicating their message properly.

Favourite saying: "Why does everybody hate me?"

8: Dux Reluctantis

The Reluctant Leader

The team had functioned well for a number of years, but there was a review and the question was asked, "Who is the team leader?" The answer was not what the big boss wanted to hear.

"You must have a team leader on every team." End of discussion.

People were invited to apply for the post, but nobody was keen. It was clear that the team dynamic was at risk and nobody wanted to rock the boat. Eventually, a person was picked, interviewed, and appointed. Even when the inevitable interview question was asked: "Why do you want this job?" the answer, "I don’t really want it," was not enough to put them off.

Sometimes, a D. Reluctantis is appointed because HR feels he needs a challenge to reveal his full potential.

Favourite saying: "If that’s okay with you…"

9: Dux Minoris

The Lesser Leader

This team leader is perfectly illustrated by Simon Travaglia’s Pimply Faced Youth (PFY) in his celebrated BOFH series of comic IT spoofs.

He is keen but has been led astray by a scheming and manipulative section manager. He is drawn into the various scams and schemes to do down the bean counters and is not above using the Argon-based fire systems to discretely dispose of those who stand in the way.

In reality, this character is easily diverted from his true path and finds himself in a tight corner when the schemes inevitably go wrong. He is great fun to work for, but you should always make sure that you take the key to the server room door with you if you enter alone.

Favourite saying: "Illegitimi non carborundum…" and he has the T-shirt to prove it.

10. Dux Severus

The Serious Team Leader

When some members of the team get promoted it goes to their heads.

Gone is the sociable, easy-going friend you worked with and out comes the martinet. The person who used to take 30-minute bathroom breaks suddenly starts to time your breaks and make scathing comments when you take more than four minutes. Having an upset stomach is no excuse because he knows that the loo break is often used as an unofficial break and an opportunity to catch up on office gossip with help desk colleagues.

Favourite saying: "We run a tight ship here."

This typifies the arrogance of the breed. Adopting the "Royal We" is always a sign that things are going to the bad.

• Leave a comment... (0)

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.

• Leave a comment... (0)

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.

• Leave a comment... (0)

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.

• Leave a comment... (0)

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.

• Leave a comment... (0)

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?

• Leave a comment... (0)

As a manager of technical projects teams, I have come to make some generalisations about IT people to help you gain a better understanding of the people in your group.

IT pros:

1. tend to be introverts

An introvert is someone who is more comfortable with an inward focus in life while an extrovert is generally more comfortable with an outward focus. For example, when introverts receive a lot of new information, they tend to want to think for a while before speaking or drawing conclusions. Extroverts, on the other hand, are more comfortable expressing ideas to others. If they jump to the wrong conclusions, they just change their minds. Basically extroverts are comfortable thinking out loud. Introverts would rather think through the "rough drafts" in their minds and then talk when they think they have a coherent and logical position.

2. tend to think more logically than emotionally

This tendency should be obvious. Technical staffers typically are not motivated by a lot of "rah-rah" speeches. In fact, they tend to be cynical of this type of motivation. They will usually listen politely (perhaps even snickering to themselves), but the effects are short-term. On the other hand, they can be persuaded and motivated by a logical argument. If the logical argument can be combined with some motivational techniques, you might have a chance to actually get them excited.

3. tend to be problem solvers

This is a strength as well as a weakness. Most technical people love being confronted with a problem. They get excited and immediately start to apply their problem-solving skills. The weakness comes in because they have a tendency to jump on a problem without fully understanding it first. Habits like that can waste resources. In many cases, the technical person will attack a problem immediately, and then have to regroup when they realise they didn’t really have a full understanding of the problem to begin with.

4. tend to be technically creative

This may seem like a contradiction. Your first thought might be that the sales and marketing staffs are the creative people. In fact they are – in the sales and marketing areas. They will also be the first to tell you so – because they are extroverts. However, the technical discipline requires a fair degree of creativity as well. This is especially true in the IT world. In many cases, there’s not one best solution to a business problem. In the development (programming) field, for instance, analysts need to be creative when they’re defining a solution with the business clients. Designers need to be creative applying technology in the best manner.

Understanding these general characteristics is the place to start if you manage a technical staff. Once you begin to understand how people work and how they’re motivated, you’ll find the best way to manage them.

• Leave a comment... (0)

I often write about managing others through problems or crises because it’s part of the day-to-day experience as a manager/leader. But what about managing yourself? You’ve probably found yourself at some point faced with a project or task that you have to tackle, but for whatever reason you can’t seem to accomplish it.

Let’s say you’re trying to attain a certification such as your PMP, CPA, or a certification in ITIL or Six Sigma. Many organisations now are asking their managers to get certifications as part of their performance/growth plans and some are tying them to future employment or bonuses, the ability to advance in the organisation, etc. In these situations, only you can learn the information. You can’t pay someone to learn for you (no matter how much you would like to).

So what do you do when you’re faced with a task like this and find that you’re not progressing as you should or maybe even failing to accomplish the task? First of all, fight the temptation to beat yourself up over it. Manage your way through the situation.

Begin by creating a plan for yourself. If you feel like you’re facing a mountain, climb the mountain by taking one step at a time. The point is to attack your own problem the way you would any other management challenge you’ve dealt with. Make your plan specific and identify milestones that you can accomplish that will give you a sense of moving forward.

When creating your plan, identify any and all resources you can take advantage of to help you accomplish your goal. You can’t delegate the task, but that doesn’t mean you can’t get help, nor does it mean you can’t delegate other tasks to give you the necessary extra time to accomplish your task.

Create an aggressive plan and stick to it! Follow your plan and schedule as if you were managing a project. You don’t take excuses from others when they fail to handle key deliverables in your project plans, don’t take any from yourself.

Divest yourself of as many duties as you can both at home and at work until you reach your goal. There are only so many hours in a day so you have to make time for yourself to work your plan.

There’s also a limit to how much energy you have to expend. Making a super human effort to accomplish your task and not changing things around you isn’t going to work. In fact, that’s probably the reason you’ve struggled and are at this juncture anyway. It’s not about burning the candle at both ends; it’s about managing the burning of the candle in order to be successful.

Celebrate your milestones and build in some incentives for hitting them on time. You probably aren’t shy about criticising yourself, so don’t be shy about rewarding yourself either.

Embrace your task. It’s more difficult to be successful if you find your task repugnant. Embracing your task will help you move forward and energise you in the accomplishment of your goal.

Don’t give your task a great deal of lip service. Create the plan, work the plan, and get it done. Whining will just help you procrastinate and aid you in giving yourself permission to fail.

Remember the goal of your plan and make sure your plan is realistic and flexible – yet always evaluate changes in your plan to see how it will affect your schedule.

Perform your risk assessment prior to forming your plan and throughout your personal project. You know what your distractions are, what your weaknesses are, etc. Identify all the things you can that may prevent you from being successful and then decide if you’re going to try to mitigate a risk, avoid a risk, transfer a risk, exploit a risk etc.

Tackling a personal challenge is never easy. Employing your management skills to your own problems makes them less "personal" and more manageable.

• Leave a comment... (0)

There are two places that scope is defined on your project. High-level scope is defined in your project charter. Low-level scope is defined in your business requirements document.

High-level scope consists of two main components.

1.Deliverables. If you can’t remember anything else about scope, list your deliverables. Defining your deliverables goes a long way toward defining the overall scope of the project.
2.Boundaries. You should also try to define the boundaries of your project. Boundary statements help to separate the things that are applicable to your project from those areas that are out of scope. Examples of boundary statements include:

* This project will affect USA operations only. All other locations are out of scope.
* We will deliver our solution to the Finance and Legal departments. All other departments are out of scope.

Think of project scope as a box. High-level scope defines the sides of the box and separates what is relevant to your project from that which is irrelevant.

Once the project starts, however, you generally do not have a lot of requests to change boundaries and deliverables. Most of the scope change requests you receive are changes to the business requirements.

Business requirements help define the detailed scope. The project deliverables are used to define high-level scope. Business requirements describe the details of the deliverables. If scope is a box, then your requirements are what fill in the inside of the box.

There are two types of requirements. They are:

* Product requirements (features). Product requirements describe the characteristics of the deliverables. If you were building a bridge, for instance, most of the requirements would be product based. These might include the number of cars the bridge would hold, the strength of the steel, the water level it needs to span, the color of the bridge, etc.
* Process requirements (functions). Process requirements describe how people interact with a product and how a product interacts with other products. For example, when you discuss how data gets moved and how business transactions flow from one point to another, you are describing process requirements. If you need to describe the requirements for billing transactions, most of the requirements could end up being process oriented. This would include how billing transactions move from orders to invoicing to accounts receivable. They can describe at what points people look up a status, how people manually update an invoice and what people should do if accounts are out of balance.

If you remember how these pieces fit together, you’ll have an easier time defining scope for your project in the future. High-level scope is defined in your charter and consists of boundary statements and deliverables. Low-level scope is defined by your business requirements. These two components together make up the entire scope definition for your project.

• Leave a comment... (0)