1. Look at the big picture. This pertains to printed resumes rather than text-based ones sent via the Web. What does your resume actually look like? Ignore the words for a moment. Is the layout clear and concise? Is the font easily readable? Remember that a sans serif font is harder to read that a serif font—though a sans serif font can look more modern. Choose your font size wisely; don’t go smaller than 11 pt type if you want anyone to read about all your accomplishments. Use bullet points, bold type, and spacing to help break up the information on the page.

2. Use strong action verbs to describe your job duties and accomplishments. You don’t want to present a laundry list of your day-to-day duties. Focus instead on the parts of your job that earn you recognition. Stress your leadership skills. For example, instead of writing that you are “involved in running a team of programmers and keeping projects on schedule,” try saying that you “manage a team that consistently meets deadlines.”

3. Be careful with your jargon. Is the important information readily accessible? If you’re job-hunting, remember that the people who initially screen resumes often have only basic technical knowledge; they might not know an MCSE from a CCNA. Don’t hide your strong points in language that no one outside your field can understand.

4. Ease up on the technical details. Remember, you’re in management now, and even though your tech skills got you where you are, it’s a different skill set that will propel you forward. Yes, you can—and should—list your technical skills, but make sure the focus is on how those skills help you manage people and technology more effectively.

5. Stress benefits, not features. Think back to your days as a hardware engineer, for example. Did you stress that the chip you designed replaced up to 10 discrete components or did you stress the greater product functionality and smaller device sizes that your customers could enjoy when they used your chip in their devices? Now, apply that logic to your resume. Don’t just say that you devised a new off-site backup strategy for the company. Point out that your off-site backup strategy reduced hardware and labor expenses by more than 50 percent, reduced downtime substantially, and increased client satisfaction 100 percent.

6. Put the bottom line on top. Translate each of your accomplishments into hours saved, money earned, and other tangible results for the company. If you can’t figure out how the things you do every day fit into the big picture, you’re doing something wrong. If you know what the moneymaking tasks are and you’re not finding time for them, you also need to reprioritize. Your resume should reflect the net worth you add to your organization.

7. Ask someone nontechnical to read your resume. If someone who isn’t especially tech savvy can read your resume and get a sense of what you do and why someone might hire you, your resume is definitely on the right track. If that person can also proofread, have them do it and your resume will quickly be ready for prime time.

These pointers were taken from the article “Seven ways to revamp your resume ,” by Abbi F. Perets.

You can find people in leadership roles almost everywhere you look. However, simply shouldering responsibilities of a leader doesn’t necessarily makea a person an effective leader. Leadership itself is a privilege and a skill. There are many leadership skils and competencies that when combined and applied, go towards making you an effective leader.

So what is empathy? Empathy is the ability to have an intuitive understanding of other people and their needs. Within a business setting, it is critical for empathy to be as widespread as possible, permeating all departments from sales to accounting to manufacturing. In today’s world, as evidenced by the terrible financial crisis of last year, there is a possibility that we could get too caught up in data. When we do that, we often fail to see truths that are right in front of us. Employees at ll levels of an organization need to understand the people beyond the office walls – their customers, their clients etc. This enables everyone to make better real-world decisions. Over time, even the smallest decisions influenced by empathy add together to produce a more informed and nimble organization.

Empathy is a necessary attribute of a great leader but i is not sufficient. A lot more is required. In fact, some highly aggressive corporate environments see empathy as a sign of weakness. A good example of such cold-bloodedness was the hot-shot chief executive Albert John Dunlap, who appeared to relish the title of ‘Chainsaw A1′, bestowed upon him for the way he could and would fire any number of employees without hesitation. Well, he was considered to be golder CEO for a while, but he ended up being denounced for an accounting fraud! And that’s the core of the matter – people who are not empathetic often end up being selfish and short sighted instead.

Effective leaders, make tough decisions when situations warrant, but hey also communicate with employees and understand what they are going through. Empathy distinguishes a good leader from the great ones, in a crises situations.

It has been understood that empathy is one quality that a leader must possess in order to be successful and it also plays a role in making an organization achieve its vision. So,, what are the behaviors that go into making any person empathetic towards others and how can this quality be developed?

Empathy can be built from three major behavior
- Recognizing your own shortcomings – past and present.
- Listening to others and learning more about their lives and their private challenges
- Explicitly aspiring to a noble deal of leadership.

If you want your business to adopt widespread empathy, there are really three steps to follow.
1 – Leave the office and get outside. Go to places where people are most likely to act like themselves.
2 – Be genuinely interested in other people. Forget about what is that you do and start caring about the needs of others. Find the real needs first and your solutions will dramatically improve too.
3 – Bring evidence of the real world back to your offices.

Empathetic leaders position people first. True empathy stems from the leader’s ability to display genuine concern towards the needs of others. High level of empathy is denoted by:
1 – Listening to people:
Pay attention to their tone of voice, to the hidden emotions behind what they are saying to you and to the context. Don’t interrupt people. Don’t dismiss their concerns offhand.

2 – Focusing on the non-verbal communication:
the body language of people often communicates what they think or feel, even when their verbal communication says something quite different.

3 – Being fully present:
when you are conversing with people, don’t check your email, look at your watch or take phone calls. Allow people to have their comment.

4 – A Smile:
it makes people comfortable and you more.

Hence, it can rightly be said that, even if you have all the qualities of becoming a successful leader, but if you miss the basic quality of feeling empathy towards your teammates, your journey towards success will be very short lived. Put yourself in their shoes and see how success touches your feet.

The Seven S approach is a framework that focuses on guiding managers to improving, not just our processes, but our entire strategic approach to the business.The Seven S approach is a framework that focuses on guiding managers to improving, not just our processes, but our entire strategic approach to the business.

So what are the Seven S’s, and how do they fit together to help consultants and managers improve business performance? Here’s a brief walk through of the attributes of the Seven Ss.

#1. Strategy: The overriding goal or objective that the enterprise wishes to achieve, and the course of action it intends to take to reach that goal. From the viewpoint of IT, the key question here is often about alignment. Are the activities of the IT staff focused on achieving the strategic goals of the organization? Is there a forward-looking IT plan or road-map that illustrates how the IT function will drive towards to long-term strategic objectives of the firm? Is the CIO involved in strategy formulation or just an implementer? Every IT professional has experienced situations in which a manager or executive becomes enamored of some technical solution, often sold to her by a sales representative as the “end-all fix,” and IT finds itself devoting all its energies to implementing a product that is disconnected from the firm’s strategic goals.

#2. Structure: The manner in which the enterprise is organized, and the relationships between the entities, such as departments, field offices, etc. Is the organization authoritarian, like the military, or decentralized or federated? How do internal processes and human resources work together to achieve the goals? In my consulting experience, I’ve seen many firms that want to migrate to an e-commerce approach to sales, and yet see e-commerce enablement as a project, rather than as a structural problem that needs to be solved. No matter how great the e-commerce engine an organization builds, if it’s internal organization and structure is not modified to adapt to this new channel, it has very little chance of success.

#3. Systems: Not just information systems and infrastructure, but also the processes and the functions that enable the organization to work, such as recruiting, accounting, and procurement. From e-commerce to data warehousing and knowledge management, and all across the array of processes and systems that companies employ to deliver their products and services, the ability to make the right technology decisions, to optimize processes, and to enhance productivity are make-or-break elements of success.

#4. Staff: The human resources that actually accomplish the work, and the recruiting, incentives, and compensation practices that encourage them to achieve. An organization’s ability to attract and retain the best talents and to keep them motivated and productive is key to execution of the enterprises goals. All the strategic innovation in the world cannot compensate for an unmotivated staff or low productivity.

#5. Style: The elusive “corporate culture” is captured here; is the enterprise customer focused and quality driven or focused on maximizing profitability at any cost? Does the enterprise strive to build a cohesive team of its staff, or does the organization view its workforce as a series of interchangeable hands-for-hire?

#6. Skills: The unique competencies that drive competitive advantage. From the “hard” technical skills of designing products and managing projects to the “soft” skills of communication and teamwork, staff capabilities are essential elements of strategic success. This element also addresses organizational skills: As we’ve recently learned in the case of General Motors, the ability of an organization to develop products or services that the marketplace values is the differentiating factor in the market battlefield.

#7. Shared Values: The core beliefs and attitudes that drive the enterprise. Values are not the mission of the company — that should be captured in the firm’s strategy. Values are about behaviors, taking the form of statements like “we’ll never sacrifice customer satisfaction for short term profit” or “we always thank the customer for choosing us.”

Seven S is just a conceptual framework; therefore, it doesn’t tell us how to fix those areas that require development. By applying your experience, reviewing the ideas found in the literature (such as Good to Great and other business classics), enlisting the insights and suggestions of members of the organization, and applying disciplines like Six Sigma where appropriate, you can help firms apply a consistent approach to strategy development and execution and improve their results and competitive position.

The Manager tag should not be your goal. It is not something by which to measure your personal worth. It’s a responsibility, and it’s a lot of work. It’s also very unfair to team members to take on their management if you don’t really know how to do it.

If you think you deserve to be in management, ask yourself these questions:

* Could you lay off an employee that you like very much because upper management needs to make cuts?
* Could you confidently promote one of your employees above others?
* Would you be able to tell an employee he or she needs to attend to his or her hygiene better?
* Can you lead a team to results without micromanaging?
* Could you say “no” to upper management when they make unreasonable demands of your staff?
* Could you take responsibility for failures of your team even if only one staffer screwed up?

1. The strategies most likely to win are the ones that are the easiest to understand. If the situation is complex, figure out a way to make it understandable. Otherwise, you’ll end up being another one of those really smart people who has no followers, no success stories, and no promotional future.

2. Emotion wins over logic 9 times out of 10. When we get emotional we generate energy and enthusiasm within others. An emotional team can get a lot done, they’ll work longer hours, and help make converts. It can beat a larger or better-equipped team without emotional buy-in. You’ll accomplish what you intend.

3. The best deals come together fast. You’ve probably experienced this before like when you were buying a car, or being hired for a new job. Things just fell into place and everyone walked away feeling good about the deal. It’s the same for new programs, or changes in business direction: If you find that the same things need to be addressed repeatedly, it’s a warning sign. It may be time to cut bait.

In many companies, and in life generally, some great projects are shelved while other poor ones get the green light. We see it with choices for technology and vendors all the time. Usually such decisions have more to do with how each side made their case, and less to do with logical comparisons of features and prices. It’s often the same, by the way, for decisions affecting who gets promoted and who doesn’t.

An effective project leader is often described as having a vision of where to go and the ability to articulate it. Visionaries thrive on change and being able to draw new boundaries. It was once said that a leader is someone who “lifts us up, gives us a reason for being and gives the vision and spirit to change.” Visionary leaders enable people to feel they have a real stake in the project. They empower people to experience the vision on their own. According to Bennis “They offer people opportunities to create their own vision, to explore what the vision will mean to their jobs and lives, and to envision their future as part of the vision for the organisation.” (Bennis, 1997)

Good Communicator

The ability to communicate with people at all levels is almost always named as the second most important skill by project managers and team members. Project leadership calls for clear communication about goals, responsibility, performance, expectations and feedback.

There is a great deal of value placed on openness and directness. The project leader is also the team’s link to the larger organisation. The leader must have the ability to effectively negotiate and use persuasion when necessary to ensure the success of the team and project. Through effective communication, project leaders support individual and team achievements by creating explicit guidelines for accomplishing results and for the career advancement of team members.

Integrity

One of the most important things a project leader must remember is that his or her actions, and not words, set the modus operandi for the team. Good leadership demands commitment to, and demonstration of, ethical practices. Creating standards for ethical behaviour for oneself and living by these standards, as well as rewarding those who exemplify these practices, are responsibilities of project leaders. Leadership motivated by self-interest does not serve the well being of the team. Leadership based on integrity represents nothing less than a set of values others share, behaviour consistent with values and dedication to honesty with self and team members. In other words the leader “walks the talk” and in the process earns trust.

Enthusiasm

Plain and simple, we don’t like leaders who are negative – they bring us down. We want leaders with enthusiasm, with a bounce in their step, with a can-do attitude. We want to believe that we are part of an invigorating journey – we want to feel alive. We tend to follow people with a can-do attitude, not those who give us 200 reasons why something can’t be done. Enthusiastic leaders are committed to their goals and express this commitment through optimism. Leadership emerges as someone expresses such confident commitment to a project that others want to share his or her optimistic expectations. Enthusiasm is contagious and effective leaders know it.

Empathy

What is the difference between empathy and sympathy? Although the words are similar, they are, in fact, mutually exclusive. According to Norman Paul, in sympathy the subject is principally absorbed in his or her own feelings as they are projected into the object and has little concern for the reality and validity of the object’s special experience. Empathy, on the other hand, presupposes the existence of the object as a separate individual, entitled to his or her own feelings, ideas and emotional history (Paul, 1970). As one student so eloquently put it, “It’s nice when a project leader acknowledges that we all have a life outside of work.”

Competence

Simply put, to enlist in another’s cause, we must believe that that person knows what he or she is doing. Leadership competence does not however necessarily refer to the project leader’s technical abilities in the core technology of the business. As project management continues to be recognised as a field in and of itself, project leaders will be chosen based on their ability to successfully lead others rather than on technical expertise, as in the past. Having a winning track record is the surest way to be considered competent. Expertise in leadership skills is another dimension in competence. The ability to challenge, inspire, enable, model and encourage must be demonstrated if leaders are to be seen as capable and competent.

Ability to Delegate Tasks

Trust is an essential element in the relationship of a project leader and his or her team. You demonstrate your trust in others through your actions – how much you check and control their work, how much you delegate and how much you allow people to participate. Individuals who are unable to trust other people often fail as leaders and forever remain little more that micro-managers, or end up doing all of the work themselves. As one project management student put it, “A good leader is a little lazy.” An interesting perspective!

Cool Under Pressure

In a perfect world, projects would be delivered on time, under budget and with no major problems or obstacles to overcome. But we don’t live in a perfect world – projects have problems. A leader with a hardy attitude will take these problems in stride. When leaders encounter a stressful event, they consider it interesting, they feel they can influence the outcome and they see it as an opportunity. “Out of the uncertainty and chaos of change, leaders rise up and articulate a new image of the future that pulls the project together.” (Bennis 1997) And remember – never let them see you sweat.

Team-Building Skills

A team builder can best be defined as a strong person who provides the substance that holds the team together in common purpose toward the right objective. In order for a team to progress from a group of strangers to a single cohesive unit, the leader must understand the process and dynamics required for this transformation. He or she must also know the appropriate leadership style to use during each stage of team development. The leader must also have an understanding of the different team players styles and how to capitalise on each at the proper time, for the problem at hand.

Problem Solving Skills

Although an effective leader is said to share problem-solving responsibilities with the team, we expect our project leaders to have excellent problem-solving skills themselves. They have a “fresh, creative response to here-and-now opportunities,” and not much concern with how others have performed them. (Kouzes 1987)

Small projects don’t necessarily require much knowledge of project management or much project management discipline. But as a project gets larger, formal processes and techniques become essential. Different project management methodologies organize and structure these processes in various ways, but we’re going to focus on 10 basic areas:

1. Define the project
2. Plan the work
3. Manage the workplan
4. Manage issues
5. Manage scope
6. Manage risks
7. Manage communication
8. Manage documentation
9. Manage quality
10. Manage metrics

In general, if you can master these areas, you can succeed in most projects. You may not have to worry about managing documentation or metrics on a small project, but the larger your project, the more you’ll need to focus on all 10 processes.

Notice that our list doesn’t include analysis, design, testing, or implementation. Those who have worked on projects probably know that they typically include analysis and testing. However, there is a major distinction to be made. Analysis and testing are part of the actual project work effort (also called a project lifecycle). These phases change depending on the project type. If you have a full lifecycle project, you could perform the full range of analysis, design, construction, testing, and implementation. On other projects, you might do only certain components. For example, if you were performing a research and development project, you wouldn’t be doing implementation. If you were performing a study, the project might end after the analysis phase.

Do you see something missing?

Two processes are sometimes included as a part of basic project management: people management and contract and procurement management. People management is an important skill for project managers, but it’s not specific to project management. After all, any management-subordinate relationship requires people management. The distinction is that it’s a project “manager” skill, but not necessarily a project “management” skill.

We’ve also excluded contract and procurement management from our list. In most organizations, project managers need to know about the management of contracts and vendors, but they aren’t responsible for it. A legal department and/or procurement department is usually responsible for these disciplines.

Timing and sequencing of the processes

Except for the first two categories — defining the project and planning the work — the 10 major project management areas don’t fall into a sequential path. Processes 3 through 10 can be done in any order, and in fact, are done in a parallel and ongoing manner throughout the project. For example, if a major problem pops up, you must use issues management regardless of what other aspects of project management you’re using before, during, or after that time. Let’s take a closer look at each process.

#1: Define the project

As the project manager, you must make sure that the work is properly understood and agreed to by the project sponsor and key stakeholders before the project work begins. You’ll work with the sponsor and stakeholders to ensure that the project team and the client have common perceptions of what the project will deliver, when it will be complete, what it will cost, who will do the work, how the work will be completed, and what the benefits will be.

The larger the project, the more important it is that this information is mapped out formally and explicitly. All projects should start with this type of upfront planning to prevent problems caused by differing viewpoints on the basic terms of the project. The major deliverable from this step is the Project Definition (some companies call this a Project Charter).

At a high level, the purpose of defining the work includes:

• Understanding and gaining agreement on project objectives, deliverables, scope, risk, cost, approach, etc. This is the most important part of defining the work and is where most of the time is spent in gaining common agreement.
• Determining whether the original business case is still valid. For example, a project that requires 10,000 effort hours might make business sense. If the more detailed definition process results in a more refined estimate of 20,000 hours, the project may no longer be feasible.
• Making sure the resources you need are available when you need them.
• Providing a high-level baseline from which progress can be compared and scope can be controlled.
• Gaining agreement with the client on the processes used to manage the project.

The effort required to define the work depends on the amount of information and the level of detail that need to be understood and documented. The duration required to define the work depends on the length of time necessary to discover and document the information, as well as the time required to gain agreement and approval from the client.

It may be difficult to define exactly what the final deliverables look like for large and complex projects. It is also difficult to estimate the total cost and deadline date. If that is the case, you can break the project into smaller projects. The projects that are done first should then be much easier to define. The projects that are to be completed in the future can be defined in detail as they get closer to execution.

At the end of the definition aspect, you should have a Project Definition that defines the expectations of the project in terms of objectives, deliverables, scope, risks, costs, deadline, and roles. This document should be formally approved by the project sponsor and other key stakeholders before the project team proceeds. At times, you can get frustrated because of the difficulty in gaining agreement with the client on scope, timeline, and cost. But that is exactly the reason this definition work is done ahead of time. Think of the problems you would no doubt encounter trying to gain agreement with the client on scope, schedule, or cost when the work had started and the deliverables were actually being produced.

#2: Plan the work

When you define the project, you make sure that you have an agreement with the project sponsor on what work should be completed in this project. In this stage, you determine how the work will be completed. This involves building the Project Workplan. You’ll take different approaches according to the size of the project. For example, the workplan for small projects can be built using a project management package like Microsoft Project, a spreadsheet, or even a piece of paper.

If you don’t have a workplan template to use as your starting point, you can use the Work Breakdown Structure (WBS), a technique for looking at the project at a high level and breaking the work into smaller and smaller pieces until you can get the full picture of the work. The entire team can collaborate on this exercise. I recommend breaking down the work into lower levels until each remaining activity is less than 80 hours, and it is clear what is required to complete the activity.

Once all of the work has been uncovered, you can sequence the activities and identify dependencies between them. At this point, the WBS has been converted to a Network Diagram.

Next, you add resources (workers) for each activity. If you know of certain resources, you can add them by name. If not, you can use generic names as placeholders. You then add the effort hours and the beginning and ending dates for each activity.

Your workplan is now ready to go. You’ll know what work you have to complete (Project Definition) and how you’ll get the work done (Project Workplan).

The relationship between defining and planning the project

You may find that you can’t complete the Project Definition without starting to lay out the overall Project Workplan. In many cases, you’ll need to work on these two deliverables simultaneously. As you gather information about scope and deliverables, you’ll need to start laying out a timeline so that you can get your hands around estimated effort and duration. When the deliverables, scope, assumptions, and approach are complete, you should have enough information in the Project Workplan to estimate the budget, effort, and duration, which you’ll use in turn to complete the Project Definition.

#3: Manage the workplan

At this point, you’ve finished defining the project and planning the work. The major deliverables in place are the Project Definition and Project Workplan. Some project managers think that defining and planning the work means that the hard part of managing the project is behind them. That is definitely not the case.

You’ll never be a successful project manager if you don’t keep the workplan up to date. Remember, the workplan is only a deliverable. It describes the work that needs to occur, the order of the work, how much effort is required, and who is assigned, but it represents only your best guess as to how to complete the remaining work at any particular point in the project.

The more complex your project is, the more change is going to be required in your workplan over time. As the project manager, you must evaluate the workplan on an ongoing basis (perhaps weekly) and determine the current state of the project.

During this weekly review, you’ll update the workplan with the current state of work that is completed and in progress. You’ll evaluate the remaining work to see if the project will be completed within the original effort, cost, and duration plans. If it can, you are in good shape. If it can’t, you must implement corrective action.

Of all of the skills of managing the project, this one is perhaps the most fundamental. Depending on the dynamics of your project, you may be in the position of having to constantly use your experience and creativity to get the project completed within expectations. One week, your project may be on track. The next week, you may have work assignments that are late and issues that have surfaced.

If an activity on the critical path is a week late, you can’t sit idly and allow the entire project to be a week late. Instead, you must evaluate the resources and options available and get the project back on track. If you’re good at it, managing the workplan can be one of the more challenging and rewarding aspects of project management. If you don’t relish the detailed work that is required, you may find it much more difficult to be successful.

#4: Manage issues

An “issue” arises when a problem will impede the progress of the project and can’t be resolved by the project manager and project team without outside help. If a major problem emerges, you have no choice but to resolve it. The only question is whether you’ll actively apply issues management to the situation or flounder through indecision and uncertainty about how the issue should be resolved.

Issues management has two major components. The first is having a process to uncover issues, determine their impact on the project, examine alternatives, and bring in people to make the best decision under the circumstances. This is all part of the project management procedures that should be defined and agreed to ahead of time. These procedures ensure that issues are recognized and resolved as quickly as possible.

The second component of issues management is applying specific problem-solving techniques. This includes some understanding of techniques such as Fishbone diagrams, Pareto charts, and root cause analysis. Having an understanding of one or more of these techniques allows you and your team to understand the nature and cause of the problem, what options are available, and what alternative would be the best course of action.

One important thing that all project managers discover is that having a process to resolve issues doesn’t mean you’ll successfully resolve every one. Sometimes, there are great alternatives to issues and your job is to help discover the best one. In other instances, there is no good resolution to a major problem. On occasion, your final choice is to pick the solution that causes the least harm or is the best among poor choices. Still, your issues resolution process and your problem-solving techniques will allow you to determine what options are available so that you at least understand the repercussions.

#5: Manage scope

Scope describes the boundaries of the project and defines what the project will deliver, what data is needed, and which organizations are affected. Given a set of resources and time, an infinite number of things can be delivered.

Scope change management starts with scope change definition. If the project manager hasn’t done a good job defining scope, it will be difficult to manage scope during the project. The purpose of scope change management is to protect the viability of the current, approved Project Definition. When the project was defined, certain expectations were set for what the project was going to produce for a certain cost and in a certain timeframe. Both you and the project sponsor have those expectations in mind when the Project Definition is developed and approved.

During the life of a project, there may be a need for items that are different from, or not included in, the original Project Definition; this is to be expected. If this occurs, the client should not expect that these items can be delivered using the previously agreed on resource and time constraints. The project team will identify the new requirements and determine the impact to the project if the new requirements are included. The information is then taken to the sponsor for approval.

Remember, the sponsor is the one who approved the funding of the work to begin with. Therefore, he or she is the one who should approve any changes to the original agreement. If the business value of the change is high enough, the sponsor should approve adding the new requirement to the project, as well as the incremental budget and timeline needed to complete the work. Everyone will then be in agreement and everyone’s expectations will have been reset.

Of course, sometimes it doesn’t happen so smoothly. Common problems include:

• Scope creep. Large scope changes are easy to spot. However, when the changes are small, sometimes you find that you’re including them without realizing it. Scope creep means that you’re accepting small changes that end up having a significant cumulative effect on the project. You and the entire team must be diligent to guard for all scope changes — big and small.
• End-user scope approval. The project sponsor is the person paying for the project. However, once the project begins, the team spends more time with lower-level clients and end users. Some project team members believe that scope changes are fine if the end user approves them. This is not the case. Unless the sponsor has specifically delegated the approval authority, these people can’t approve scope changes. They can raise scope change requests, but only the sponsor has the funding authorization to approve incremental work.
• Team members not being accountable. A common cause of missing deadlines is that the team members end up doing more work than required. For example, a team member may be asked to create a report. As he or she is creating it, the client asks for new information. The team member tries to accommodate the client, and the work ends up being late. This happens when team members think that only the project manager needs to worry about scope change management. They need to understand that it’s everyone’s responsibility.

The root cause of many unsuccessful projects is poor scope change management. Defining and managing scope effectively will increase the chances that your project will meet expectations.

#6: Manage risk

Risk refers to future conditions or circumstances that exist outside the control of the project team and that will have an adverse impact on the project if they occur. In other words, whereas an issue is a current problem that must be dealt with, a risk is a potential problem. Reactive project managers resolve issues when they arise. Proactive project managers try to identify and resolve potential problems before they occur. This is the science and art of risk management.

Since smaller projects usually don’t have long durations, there is less opportunity for problems to develop. Larger projects usually have risks lurking just over the horizon. Risk management involves identifying all potential risks to the project, determining how likely they are to occur, and understanding the impact on the project if they occur.

With that information, the project team can determine which risks should be actively managed. For example, a risk with a high probability of occurring and a large impact on the project should definitely be managed proactively. On the other hand, a risk that has a high likelihood of occurring but a marginal impact on the project can probably be ignored.

Once you identify which risks you want to actively manage, you can invoke five general responses:

• Leave it. You would leave a risk if you determined that your project would not be harmed if the risk occurred or if there was nothing that could be done to address the risk and you’re willing to take the chance that it won’t occur.
• Monitor the risk. In this case, you don’t proactively mitigate the risk but you monitor it to see whether it’s more or less likely to occur as time goes on. If it looks more likely to occur later, the team must address it at that time.
• Avoid the risk: Avoiding the risk means eliminating the condition that’s causing the problem. For example, risks associated with a particular vendor might be avoided if another vendor is used.
• Move the risk: In some instances, the responsibility for managing a risk can be removed from the project by assigning the risk to another entity or third party.
• Mitigate the risk: In most situations, this is the approach to take. If a risk has been identified and is a concern, you can develop a proactive plan to ensure that it doesn’t occur.

As with scope changes, there is nothing inherently wrong with having risks on a project. Clients don’t expect that a project will be risk-free. What matters is the project management response. If risks are identified and actively managed, the project has a much better chance of success. If risks are ignored, the project will be negatively affected when the risks turn into issues. At that time, there may be fewer options for resolution without impacting the project.

#7: Manage communication

Properly communicating on a project is critical for managing the clients and the shareholders. If they’re not kept well informed of the project progress, there is a much greater chance of problems and difficulties due to differing expectation levels. In fact, in many cases when conflicts arise, it’s not because of the actual problem, but because the client or manager was surprised.

There are two levels of communicating on projects. First, all projects should communicate status. Second, if your project is larger, more complex, or more politically charged, you need a higher and more sophisticated level of communication defined in a Communication Plan.

Status meetings and status reports

All projects need effective communication from the project team to the project manager and from the project manager to the rest of the stakeholders. Status reports and status meetings need to do more than just say whether the project is on track. This is the time you communicate everything you think needs to be known about your project. You communicate about adherence to the project’s budget and schedule, accomplishments from the last reporting period, planned accomplishments for the next period, new risks, current issues, and current scope change requests.

The information and presentation must be communicated with the audience in mind. Therefore, you would expect that a weekly status meeting with your team would include discussions at a fairly low and detailed level. Status reports you send to the sponsor and management stakeholders will necessarily be brief and high-level.

Communication Plan

Large initiatives, especially the kind that require organizational change, must include an overall Communication Plan that takes a multifaceted approach to communication. The process for building this plan includes defining all your stakeholders, determining what information they need, brainstorming ways to deliver that information, and then deciding on a set of communications that cover as many stakeholders as possible in the most resource-efficient manner.

Depending on the audience, the communication falls into one of three areas.

• Mandatory. This includes status reports, budget reports, and legal and auditing requirements.
• Informational. This is communication that provides extended information for people with a need to know more. Examples include a document library, frequently asked questions (FAQ), and a project Web site that contains relevant project information.
• Marketing. This is communication designed to build enthusiasm for your project. Examples include publishing success stories, building a positive image, distributing management testimonials, and using a project logo.

Communication must be handled proactively by the project manager and must be planned and executed with a purpose in mind. If you communicate effectively and proactively, you’ll find that the entire project runs more smoothly and with less conflict and frustration.

#8: Manage documents

Many project managers take document management for granted until they’re inundated with hundreds of documents. It’s better to estimate the volume of project and project management documentation you think the project will produce, establish the proper processes and rules to organize the documentation, and then manage the documentation during the project to ensure that it doesn’t get out of control.

Project managers on smaller projects don’t need to give as much thought to managing documentation. As projects get larger, the documentation definitively needs to be actively managed. Problems at their simplest include documentation that gets lost or is hard to find and work that ends up being duplicated. At its worst, document versions get out of order, document updates get over-posted and lost, and confusion and uncertainty reign.

This is an aspect of project management that may be supported by a tool, such as a document repository. However, tools can be just as confusing if proper techniques aren’t used to store documents in a manner that allows them to be easily retrieved.

Document management involves simple and complex tasks. A simple activity, for example, is a document-naming convention. If you have 10 people on your team and each one submits a status report each week, it’s not long before you have hundreds of documents. It’s easier to organize the documents if everyone uses a common naming convention. Should the name of the document start with each person’s name? If so, then each person’s historical status reports will sort together and be easier to find.

Or perhaps you’ll want to search for status reports from particular points in time. In that case, the status reports should start with the date. Then all the status reports for a particular reporting cycle will sort together.

Another part of document management is understanding the types of document tools you’ll use. For example, you might define Microsoft Word as your standard document editor. If your team is cross-functional and includes clients, vendors, and suppliers, these types of document management rules become more vital.

Other factors must be considered to successfully manage documents. These include where you’ll store the documents, how they’ll be organized, access and security rules, keywords/indexing, naming standards, versioning, completion status, retention/purging, backups, and standard template formats.

#9: Manage quality

Quality is represented by how close the project and deliverables come to meeting the client’s requirements and expectations. In other words, quality is ultimately measured by the client.

The project team should strive to meet or exceed the client’s requirements and expectations. Sometimes there is a tendency to think that “quality” means the best material and equipment and zero defects. However, in most cases, the client doesn’t expect, and can’t afford, a perfect solution. If there are just a few bumps in the project, the client can still say that the project delivered to a high level of quality.

On the other hand, a flawlessly designed, defect-free solution that doesn’t meet the client’s needs isn’t considered high quality. The purpose of the quality management step is to first understand the expectations of the client in terms of quality and then put a plan and process in place to meet or exceed those expectations.

Because quality is defined by the client, it may seem that it is completely subjective. However, plenty about quality can be objective. This requires first breaking down the generic term of “quality” into a number of areas that define the characteristics of quality.

For example, you can think of a quality computer application in terms of response time, look-and-feel, ease of understanding, level of help documentation, and absence of defects. Once you’ve defined the more tangible characteristics of quality, you can look at each of them to determine how they can be measured with more objectivity.

Quality management is not an event: It is a process and a mindset. A consistently high-quality product can’t be produced by a faulty process. You need a repetitive cycle of measuring quality and updating processes.

Collecting metrics is vital to making the quality management process work. So, the ninth and tenth aspects of project management, managing quality and managing metrics, are closely tied. If you want to do a good job of managing quality, you must measure.

When the project is initially defined, the project team must understand the expectations of the client in terms of quality and plan the activities to meet those expectations in a Quality Plan. The Quality Plan contains completeness and correctness criteria so that the project team knows what the quality expectations are.

The Quality Plan also contains the two general quality processes: quality control and quality assurance. Quality control activities ensure the deliverables produced by the project meet client expectations. An example of a quality control activity is an inspection of each component that will be used to complete a final deliverable. Quality assurance activities ensure that the processes used to create the deliverables are of high quality. An example of a quality assurance technique is a checklist that contains all of the steps that a deliverable must complete before it reaches final acceptance.

One of the purposes of quality management is to find errors and defects as early in the project as possible. Therefore, a good quality management process will end up taking more effort hours and cost up-front in the project. However, focusing on quality early has a large payback as the project progresses. For example, it is much more efficient to spot problems with the business requirements during the analysis phase of the project than to redo work to add missing requirements during the product testing. It’s also much cheaper to find a problem with, for example, a computer chip when the chip is manufactured than to replace it when a client brings the product in for service after a purchase.

#10: Manage metrics

Gathering metrics on a project is the most sophisticated project management process and can be the hardest. Because metrics can be difficult to define and collect, they’re usually ignored or handled poorly. All projects should be gathering basic metric information regarding cost, effort, and cycle time. However, you must also collect metrics that determine how well the deliverables satisfy the client’s expectations and how well the internal project delivery processes are working. Depending on the results, you can undertake corrective action or process improvement activities to make the processes more efficient and effective.

Managing metrics and managing quality are related. It is difficult to improve the quality of your deliverables or your processes if you’re not gathering metrics. Metrics are used to give some indication of what the beginning state of quality is and whether quality is increasing or decreasing.

Many metrics can be gathered on a project. The project team should identify and collect a balanced set that provides the most value. To determine the right metrics for your project, you:

• Identify the project success criteria in terms of product deliverables and project execution. That is, determine what your deliverables need to look like for the project to be successful. Also determine how your project needs to be completed to be considered successful-for example, budget and deadline expectations.
• Brainstorm a set of metrics that provides an indication of the state of each success criterion.
• Look for a balanced set of metrics that provides indications of success in terms of cost, delivery, quality, and client satisfaction.
• Prioritize the potential metrics to come up with a list that provides the most value in the most cost-effective manner.
• Set targets to allow you to determine success. Metrics are rarely of value alone. The value comes in measuring where you are against a preferred state or agreed on target.
• Add collection activities to the workplan to ensure that people are responsible for the metric collection and analysis process.

In general, metrics management is of less value on smaller projects because there isn’t enough time to capture the data, analyze the results, and make appropriate process improvement changes. Longer projects give you time to use a feedback loop. The most value is gained if the metrics are used to drive improvements on an organization-wide basis.

1: Pro Wrestling Project Management

Much like the world of professional wrestling, the world of project management can be filled with empty threats, posturing, feuds, rivalries, and unusual alliances. But what if the similarities were made an official part of project management? Let’s face it, I think we have all (at least once) dreamed of putting stubborn clients into a headlock until their faces turned purple, or maybe seeing the project manager spend 20 minutes in a steel cage with the operations manager. To really make it an authentic experience, managers would be required to enter conference rooms to music and perform a variety of poses designed to intimidate any other managers.

2: The Rolling Stones Development Model

During their extensive career, The Rolling Stones have produced a song for every occasion — and nearly everyone is familiar with their most popular tunes. So it seems like a perfectly logical jump that instead of “standard communications,” one could run an entire development project using sound clips from various Stones songs. Is the client demanding an impossible timeline? “You Can’t Always get what You Want.” Is their favorite feature impossible to code up in a way that makes them happy? “I Can’t Get No (Satisfaction).” Is the project in deep trouble? “19th Nervous Breakdown.”

#3: Bug Bounties/Penalties

Ever feel like half your day is spent cleaning up someone else’s mistakes? It’s even worse when you find out that the person who is making you feel like your job has been reduced to “clean up on aisle two” is earning as much (or more) money than you are. Imagine for a moment that any problem that could be definitively pinned on a co-worker’s poor quality of work would have a financial penalty attached to it, and that the person who fixed it would get that same amount of money. Would that co-worker’s mistakes be such a headache then? Probably not. I suspect many of us would look forward to them!

#4: Jargon-free Communications

Sometimes, listening to a manager (or worse, a salesperson) feels like you’re reading a Tom Clancy novel, with all of the acronyms, industry-specific slang, and other incomprehensible jargon. It seems like every other sentence requires more time to decipher than it took to say it. I think we can all agree that if management started using real, standard English (or your local language of choice) instead of these marketer-speak filled, incomprehensible messes, the world would be a better place. Unfortunately, we are probably more likely to see a wrestling ring put into the lunchroom (see #1) before that happens.

#5: Geek Games for Performance Reviews

Most of management’s existing techniques for measuring performance simply look at the wrong factors. Ever notice that they count the times you were late to arrive but ignore all the times you were in the office at 11 PM patching servers or writing critical pieces of code? What is really needed is a metric for overall geekiness. A much more effective review would be a pentathlon challenge, testing each employee in the following critical areas:

• Knowledge of sci-fi and fantasy movies and books
• Ability to stay in-character over a five-hour role playing session
• Modern video game skills (FPS death match)
• Classic video game skills (Super Mario Brothers speed completion)
• Ability to identify ancient computer hardware and make it work

I think with this kind of review, it would be easy to ensure that raises and promotions went only to those who have what it takes to be top-flight technologists.

#6: Charging for Dumb Questions

Remember when you were in school, and the teacher told you, “The only dumb question is the one you don’t ask?” Well, from what I can tell, that rule goes out the window the moment you become an IT worker. Your day is now filled with giving answers to dumb questions from people who won’t understand the answers anyway. Management loves to bandy about the saying, “Time is money.” Let’s put these two ideas together. If management wants us to spend our time answering questions, that’s fine; we’ll simply charge them for it. Under this new policy, all IT employees will be given a mobile device that allows them to time any useless interactions with management and record the manager’s name. At the end of the month, their department will be charged at “standard consulting fees” (say, $250/hour), which is then put into the IT department’s budget, earmarked for perks like new PCs, raises, and other niceties.

#7: No Degree? No Problem!

Most of those who are in the know in the IT industry realize that college degrees and even many industry certifications don’t directly translate into real world IT experience, let alone the ability to do the job. Try telling that to the HR department, though. Sure, many roles within IT can benefit from formal, academic-style training (people writing compilers and device drivers come to mind), but those positions are fairly uncommon. However, for the typical IT worker, dropping the college degree or certifications from the “mandatory” list would be a wonderful thing. Not likely to happen in our lifetimes, but one can dream.

#8: Siskel & Ebert 360 Reviews

The 360 review is a model in which everyone on the team reviews everyone else. Of course, this promises that the workers get to review management. Wouldn’t it be sweet if this was done in a “thumbs up/thumbs down” format, complete with bickering over things like the manager’s handling of weekly meetings, the quality of his or her memos, and the tone in which the team is addressed? I can picture it now: “Well Bob, to be honest, Sally is really lacking in the leadership department. When she tries to give constructive criticism it sounds like she is really phoning in the performance. A thumbs down from me!”

#9: Relevant Manager Dashboards

At one job I had, I created a number of “manager dashboard” reports. I think we are all familiar with these. They’re supposed to show the manager’s world at a glance. The more it tries to look like the instrument panel of a car or airplane, the less likely it is to show any information that actually relates to the project at hand. To make matters worse, IT projects are pretty difficult to quantify, so you end up with dashboards that don’t really mean much of anything at all.

I propose that we put together some dashboards for our bosses that show what we think the bosses need to know at a glance. We could have a thermometer indicating the team’s frustration level and a tachometer for hours worked per week… with anything over 40 being the “red zone.” We could also put in some idiots lights. But instead of saying “check engine” or “change oil,” they will indicate “team nearing mutiny” and “Jim needs a vacation.”

#10: Better Project and Team Names

Okay, we’re going to violate #4 here. We recognize that management is going to insist on keeping codenames and acronyms for projects and teams. So why not have codenames that make us feel like we are part of something interesting, at the very least? In other words, if the project is about to be named “Project Happy Kitty Cats” it needs to be named something better. Like “Operation Cthulhu” or possibly “Project Thor’s Wrath.” Likewise, instead of boring team names, such as “QA” or “Network Operations,” we should have much more colorful names. I’m not suggesting that the development team be renamed “Cobra” (and the supervisor be known as “Cobra Commander”), but how about renaming Tech Support to “Really Trying to Fix Mistakes”, aka “RTFM?”

Professor Daniel Ames, with a colleague in the Management Division, Frank Flynn, centered their research on coworker evaluations of their MBA students. Former coworkers commented on the students’ strengths and weaknesses and also rated their leadership potential. When asked, “What’s holding this person back from being a great leader?” the answer that came up most often was assertiveness. This was mentioned from both sides of the coin, with some people described as too overbearing and others described as not assertive enough to stand their ground.

The reason assertiveness comes up so often is that conflict is such an essential part of what managers and leaders deal with. He said,

“Sometimes it’s avoiding conflicts that really beg to be embraced and engaged in. Other times it’s pushing too hard and straining relationships through conflict.”

There’s variance across situations as well:

“Someone who’s a real mouse to their immediate supervisor might turn around and be an absolute terror to the people who work for him or her.”

I think, too, that the motive or outcome behind “winning” has something to do with the effectiveness of assertiveness. A leader who wants to win just for the sake of winning is less effective than the leader who is going to bat for something he or she believes in. But even then, a highly assertive person (even if they’re fighting for the right reason) may not see the consequences of his behavior. For example, he doesn’t see that the person he just dealt with is feeling frustrated or angry — feelings that can linger and affect the next interaction – all that is important is the win.

Middle levels of assertiveness tend to be associated with more effective leadership:

“We find what is essentially an inverted U between the ratings of a person’s assertiveness and the ratings of their leadership: up to a certain point it’s positively associated, and then it goes back down.”

How do you make someone who is too assertive less so? And how do you make a meek person more assertive? Ames recognizes that you can’t change someone’s character. But with the right kind of coaching, you can alter the person’s behavior.

Early in my career, I was assertively-challenged, if you will. But that gradually changed the more time I spent in the working world. I saw that assertiveness is not anger, and that there are just times you need to push your case.

• Don’t make a plan without talking to your manager first. This one has always been a huge hurdle for me, given that I’m so tactical and immediately start thinking in flowcharts and mock-ups as soon as I’m presented with a problem. But it’s imperative that you not come up with a fixed plan of action on a goal without first conferring with the manager who is going to be responsible for making that plan a reality. The greatest risk here is that you talk through a project with your peers or—yikes—your boss and set some level of expectation that you feel pressure to meet. No offense, but your idea could be off-base, and when it comes to tactics, managers who report to you are better sources than your boss. They actually do it every day.
• Answer the “Why?” question first. When you first roll out a new project to your manager, come with a sheet of desired metrics or goals and a quick synopsis of the benefits to the company. A PowerPoint is probably overkill here; just tell the manager what the company wants to accomplish in general terms. The correct starting point is: “The company is going to outsource some desktop support in the third quarter, and we need to get some user environments standardized,” not “We’re moving to Office XP, so go shop for some upgrade prices.” Make it clear that the goals are not negotiable, but the path to them is still to be determined.
• Compare notes. Have a follow-up meeting with your manager in a few days and evaluate what he or she has come up with. This is one context where I think it’s best to tone down the manager/employee vibe and just collaborate. This atmosphere lets you present your own ideas in a way that your manager won’t resent.
• Be sure to include some input from your manager. The worst thing you can do is ask someone what he or she thinks and then completely blow off the person’s ideas. With managers, this risk is amplified, because they think a lot—maybe more than you know. Even if some of the feedback is pretty far off, mold some of your manager’s ideas into usable forms and include them in the plan. If everything you hear is just wacko, you have a deeper problem than just the project.
• Look out for the “Just tell me what to do” response. This is the big red flag that you’ve probably gone too far and actually are “micromanaging” your manager into frustration and maybe even fatalism. You don’t want managers to do what you tell them; you want them to understand your goals and then go make them happen (believe me, it’s a lot less work). If managers just throws up their hands and check out of a project, you can bet the ground-zero staff is going to do the same thing, and you’ll find yourself pounding out Java code to meet a deadline instead of coming up with your next big idea.