Archives for 2000

Parse document-related activities into a series of smaller activities.

by Neal Whitten, PMP, Contributing Editor

I FREQUENTLY REVIEW project plans. A common weakness I encounter is the underplanning of project documents. Project documents include any documents that must be prepared and approved during a project; examples are requirements, specifications, contracts with vendors, design documents, test plans, and publications that will be delivered to the client along with the final product.

For example, if a project plan identifies an activity as “Test Plan” and shows a duration of six weeks, what does this mean? Does it mean that the Test Plan document can be prepared, reviewed, updated, and approved all in six weeks? Or does it mean only that the Test Plan will be prepared? Big difference!

Document-related activities should be parsed into smaller, more discrete activities when developing a project plan. These discrete activities are referred to as document implementation phases. The logical sequence of these phases is preparation, review, update, approval, and refresh. Let’s briefly look at each of these five phases.

Preparation. This is usually the longest of the phases and can vary from several hours for very small, simple documents to many weeks for large, complex documents.

Review. This phase begins when the document is distributed for examination. This phase is typically several days to several weeks in duration, depending on the document type, size, and availability and proximity of reviewers. Documents distributed for review should be essentially complete—no sections should be missing or significantly deficient. The goal is for all information to be available, complete, and accurate.

Update. This phase is used to modify a document in response to comments from reviewers. Time is set aside to react to comments and concerns that, once addressed, will ensure a better product or project. This phase may be from several days to several weeks in duration depending on the document and the quantity and complexity of the problems identified. All updates to the document should be highlighted, such as the use of revision bars in the margins. This will allow reviewers to locate quickly the most recent changes to the document.

Approval. This is the final opportunity for responses on a document. This phase is called approval because final agreement on the document’s contents must be reached here. This phase might take from several days to several weeks.

Refresh. The last phase is used to record any changes to the document that have occurred during the approval phase. The document is then distributed for information purposes only; no more comments are expected or solicited. This phase could take as little as one hour or as long as several weeks.

Some documents might need only the three phases: preparation, approval, and refresh. These documents are typically small in size, cause little controversy, and would require little change from a first review. Documents that require all five phases are those that are considered critical or complex project documents. To omit the review and update phases for documents that are considered primary is usually a grave mistake.

Although the five phases described here are adequate for most documents, you might choose to identify other phases for some documents. For example, separate phases related to customer validation or inspection might be added.

However many phases you assign to a document, it is important to separately identify, plan, and track these phases. Returning to our original example, “Test Plan—6 weeks” is better planned and tracked by parsing that document into smaller activities, such as Prepare Test Plan—2.5 weeks, Review Test Plan—1 week, Update Test Plan—1 week, Approve Test Plan—1 week, and Refresh Test Plan—.5 weeks.

PROJECT PLANNING IS all about getting in control. Dividing a document-related activity into smaller activities helps you do just that.

Progress on a project cannot be measured unless a plan has been established against which it can be measured.

by Neal Whitten, PMP, Contributing Editor

Last month’s column (Part 1) addressed frequently asked questions about project planning. This column continues the focus on and the questions most frequently asked about effective project planning.

Q. What is the difference between a top-down plan and a bottom-up plan? A top-down plan typically is developed by one person (or a small subset of people on a project). It suggests a set of high-level schedules, costs, and risks. A top-down plan should not be conveyed to management or the client as a committed plan, only as a targeted plan. Top-down planning is an essential business exercise that helps stakeholders get a better feel for the size, cost, and complexity of a project. A bottom-up plan is developed with the participation of virtually all members of a project. All activities are identified (not just the significant ones), along with the activity owners, activity durations, the dependencies among activities, and other information. A bottom-up plan represents the plan that should be committed and is considered reasonable risk.

Q. Contracts are often based on top-down planning. Are you saying that these plans should not be committed? It is not realistic to wait for the critical mass of project members to be onboard before estimating plan commitments for a contract. With contracts, it is important that the final proposal be carefully reviewed before it is submitted. It also should include sufficient contingency to help address the unknown.

Q. Who should approve the project plan? All stakeholders. Project members approve their own portions of the project plan as well as those portions that affect their domain of responsibility. For the project manager, this translates to having approval rights on the entire plan. Resource managers approve those portions that affect their resource commitments. The product manager, sponsor, and/or client approve the major aspects of the plan such as scope, schedules, costs, and quality.

Q. Who has the final say on the approval of the project plan? The person in management who has the most at stake based on the successful outcome of the project has the final approval from within the project’s organization. The project manager works on behalf of this person, often called the product manager or sponsor. However, ultimately, the client has the final approval if the project is directed toward a specific client.

Q. When should a project plan be replanned? Routine changes to the project plan will occur as a result of the change control process chosen to address changes in scope. As a result, in some cases, it is possible that significant portions of the project plan must be replanned. However, other events could trigger replanning a project. Examples include if the project schedules/costs are continuing to erode and the original plan is no longer achievable, or if there are changes in the project’s ground rules that could affect the plan (for example, availability of resources and/or shifting priority of project). Consideration also should be given to replanning the project at the end of major phases. When a project is first planned, many assumptions are made. As the project achieves its major phases or milestones, better data is available from which to plan.

As last thoughts for you from these frequently asked questions, I have three: (1) Learn from the wisdom, “We never find time to do it right, but always find time to do it over.” Performing thoughtful planning the first time is always the best business choice. (2) The best project plan is aggressive, but achievable. Aggressive to maintain a healthy rate of productivity and competitiveness; achievable so that all stakeholders win. (3) Project planning is about getting in control; project tracking is about staying in control. The progress on a project cannot be measured unless a reasonable plan first has been established against which progress can be measured.

Note: In response to a reader’s comment, here is an update relative to “Who should approve the project plan:” Anyone whose domain of responsibility is affected by the project plan must have the ability to approve his or her dependencies and commitments. That approval could either be direct or through a representative.

“The beginning is the most important part of the work,” said Plato. I agree!

by Neal Whitten, PMP, Contributing Editor

Effective project planning is vitally important to the success of a project, yet on many projects planning is weak. Here are responses to some frequently asked questions about this crucial activity.

Q. What is the primary purpose for a project plan? Project planning is about getting in control. Until a project has a comprehensive plan to follow, it cannot convincingly be defended as being under control. The project plan serves as a road map of project activities, is critical to achieving a healthy productivity rate for the project’s members, is the keystone for project communications, and is the baseline from which to gauge progress. Note: Project tracking is about staying in control and can only be effective after a reasonable plan is in place from which to track.

Q. When should a project plan be started? A preliminary project plan should be available within the first week that a project manager (PM) is assigned to a project. It should address the next two to four weeks of activities and requires no approval other than by the PM. It is used to ensure that the PM, as well as project members coming onboard, are making reasonable progress. Until a comprehensive project plan can be put in place, the PM must always have a near-term plan from which to pace progress.

Q. What events should occur before a comprehensive project plan can be created? Minimally, these events should occur: the project manager is assigned; the requirements (problems to be solved) are completed and approved; a scope statement (very-high-level solution addressing the problems) is completed and approved; and a critical mass of project members are assigned and working the project. For some projects, detailed specifications or a statement of work also is completed and approved. For the more process-mature projects, additional exhibits are in place, such as a project management methodology and a project charter defining, among other things, roles and responsibilities.

Q. It appears that the PM is responsible for the project plan. True? True. The project plan is created according to the direction given by the project manager. Every project member contributes to it, and the PM ensures that all aspects of the plan are carefully reviewed and approved. The PM defends the right plan on behalf of all project stakeholders and is held personally accountable for both the completeness and the performance of the plan.

Q. Is it wrong for the client, sponsor, or head executive to preset the project completion date? Not at all! This date is helpful to allow the project team to understand the sense of urgency of the project and to attempt to achieve the target date. A problem arises only if the project team cannot possibly achieve the target date, yet it is mandated anyway.

Q. Referring to the last question/answer, what can the PM do if directed by a superior to provide a plan that, on paper, appears to achieve the end date but in reality is unrealistic? The project manager has the responsibility to defend the right plan. If the PM is unsuccessful, then several steps can be taken. (1) Solicit a respected third party to assess the reasonableness of the project plan with the expectation that that person backs up the PM’s assessment. (2) Put metrics in place so that early warning signs can be seen if the progress of the project plan begins to wane. (3) At the end of each major phase of the project plan, add the activity, “Resize Project Plan.” This will allow a more accurate estimate for the remaining phases.

Q. But what if the project end date is contractual? Isn’t it a waste of time to resize the project? All the more reason to resize the project when better estimates can be provided. If you have a committed project completion date, it is imperative to understand the obstacles so that they can be mitigated. Perhaps the original end date cannot be achieved; however, everyone will be pulling together to minimize the damage.

NEXT MONTH, IN PART 2, I’ll respond to more frequently asked questions about project planning, while continuing on a quest to add more thoughtfulness to an often ineffectively performed activity.

Rather than just talking about the improvements you want, why not plan and execute them.

by Neal Whitten, PMP, Contributing Editor

THIS SHORT ARTICLE MIGHT SAVE you a lot of time and money. It could even be the cause of decreasing your time-to-market and increasing your revenue/profit, quality, and customer sat ratings! Skeptical? Read on.

Here is a highly effective approach that I frequently use with clients to help them improve the performance of their organizations and the projects within those organizations. However, you don’t need an outside consultant to make this happen.

1. Invite People to a Brainstorming Session. The participants come from across the organization and should be the power players-the leaders. These are people who typically have the most knowledge and experience about the processes, tools, and products. Strive to have a large percentage of the participants be other than managers.
2. Conduct the Brainstorming Session. The objective is for the participants to brainstorm, identifying the most important problems facing the organization that, if properly addressed, could have a positive, measurable impact on the overall performance of the organization. Depending on the size of the organization, this session might include from five to 20 persons and take from one to three hours.
3. Identify the Top Three to Five Problems to Solve. After a reasonably exhaustive list of key problems has been brainstormed, select the top three to five problems. An effective approach is to list all the brainstormed problems on flipcharts and attach these charts to the meeting room walls. Then, with everyone participating, assign a weight to each problem such as high, medium, and low. There may be anywhere from 10-50 problems identified, but only a relatively small number will be judged high. Identify the most critical.
4. Assign Owners to These Problems. A different person should be assigned to champion the solution of each problem. These owners have the responsibility to drive these problems to closure and will be evaluated on their results (not effort) to institutionalize the solutions across the organization.
5. Create a Project Plan for Addressing Each Problem. Deriving the solution for each problem and institutionalizing that solution becomes a project plan. The assigned owners now become project managers and each project manager will plan and track his or her project through its completion. The plan will show that many members will play a role on each project, even if the role is only to review and approve appropriate deliverables.
6. Track Each Project Plan Weekly. A senior project manager (SPM) is assigned to review weekly the progress of each plan. The SPM works, one-on-one, with each project manager. This step is essential as a check-and-balance to ensure that these plans are progressing as needed.
7. Repeat Steps 1-6 Every Six Months. After the top three to five problems have been addressed, now identify the next layer of top three to five problems and work them off in the same fashion.

Here’s a sample list of common top problems that frequently surface; the problems are listed as “what is needed”:

• Clearly defined roles and responsibilities for project members (for example, project manager, team leader, business architect)
• A consistent project management methodology defined, documented, and followed
• An effective portfolio management process to nominate and prioritize projects
• Dedicated project managers and resource managers
• A defined and communicated awards program.

A project plan for, say, the first bullet, might include milestones such as the following: define and obtain agreement on the problem; draft a high-level solution to the problem and have it reviewed by a short list of peers; draft the solution and have it approved by the appropriate organization’s members; train the members of the organization so they understand the roles and responsibilities; enforce compliance as new projects are started.

MY EXPERIENCE SHOWS that almost all problems can be solved and institutionalized within three to six months. Now that’s progress!

Do what’s best for your domain of responsibility, not what’s best for your company.

by Neal Whitten, PMP, Contributing Editor

WHEN YOU START WORK each day, do not focus on moving your company forward. If possible, do not focus on your company at all. Yes, you read correctly.

Instead, channel your energies on successfully completing your assignments … your domain of responsibility. If everyone in your company focused on his or her domain of responsibility, the company would do just fine. In fact, your company probably would be more successful than it is today.

What do I mean by your domain of responsibility? It includes all responsibilities and commitments that fall within the scope of your assignment. This is the area for which you are accountable. Whether you are a one-person project, a member of a 10-person project, or a member of a 1,000-person project, your project’s success-and, therefore, your company’s success-has a direct relationship to how well you perform in your domain of responsibility.

If you reach outside your domain of responsibility and attempt to fix or improve something there, I view this to be extra credit in terms of your actions and your performance. I am not a proponent of pursuing extra credit, especially if that extra credit is at the sacrifice of successfully completing your commitments in your domain of responsibility. It has been my experience that if one focuses superbly in his or her domain of responsibility, one’s contributions and overall career will shine brightly-even without the extra credit.

It is important to understand the difference between your domain of responsibility and extra credit. Let’s look at an example.

You are a project manager of a new project. You also are a member of an organization that has many projects managed concurrently. The organization does not have well-defined project management best practices that you can adopt for your project. Therefore, you (or others at your direction) must define satisfactory practices to be followed on your project. The pursuit of these tasks is not extra credit because you need well-defined practices to support the success of your project.

However, the project management practices you define should be created only for your project. They should not be designed and documented to become institutionalized for other projects to use. If they are prepared in a manner to be used beyond your project, then these actions are examples of extra credit. To perform the extra credit would require much more time to be invested at the expense of your project.

In the course of performing your commitments, any action that you feel you must perform in order to successfully complete your commitments becomes a part of your domain of responsibility. It often is easy to shrug off being accountable for items that require other people’s/organization’s/company’s actions. But if these actions are required to successfully complete your commitments, it becomes your duty to ensure that these actions occur.

Here are a few examples of items that are in a project manager’s domain of responsibility but often are weakly pursued:

• Adopting/defining PM best practices for the project
• Ensuring client participation
• Obtaining commitments from others and then holding them accountable
• Escalating project-related issues to achieve their timely closure
• Enforcing effective change control to manage scope creep
• Defending the right project plan to the project sponsor, executives, or client
• Boldly driving your project to a successful completion, not waiting for someone else to do it for you.

FOCUSING ON YOUR DOMAIN of responsibility doesn’t mean that you don’t care about your company. Your actions demonstrate the opposite. The success of your assignments strengthens the success of your company. If you want to turn a company around, then turn around the thinking of the members of that company. Refocus the members on being accountable for their domains of responsibility and the rest will follow.

Use this agenda to navigate your project meeting and stay a course for maximum results.

by Neal Whitten, PMP, Contributing Editor

LAST MONTH’S COLUMN addressed frequently asked questions about project tracking meetings. As a follow-up, this column addresses the major subjects of focus at these meetings. While project tracking meetings can be conducted in a wide variety of formats, I have found the following approach to be especially effective. These subjects are presented at tracking meetings in the order described here.

Project High-Priority Areas. The project manager displays the top three to five problems now plaguing the project, while their “owners” report any late-breaking news. These problems are currently impacting a major project milestone (often called an “issue”) or have the potential (called a “risk”) to do so. The project manager tracks these high-priority areas daily, all other project progress/problems are tracked weekly.

Overview of Project Progress. The project manager presents this information on a single chart that lists the project’s major milestones. The chart is first presented as a high-level view of the project plan and is updated for each tracking meeting to illustrate the “big picture” of where the project’s progress is in relation to where it was planned to be. This chart has special interest to the project’s sponsor and client. It is expected to be a reasonably good view of the forest without obstruction from all the trees. The chart likely will require updating by the end of the tracking meeting after all participants have presented their status.

Progress of Project Activities. Each participant of a project tracking meeting presents their status against their portion of the project plan. This status includes metrics to substantiate the progress made, identifies their top three to five priorities and their corresponding status, and a 30-day outlook of what can be expected, including whether or not help is required.

Progress of Action Items. An action item is a project problem that is logged, assigned to an owner to resolve, and then tracked until it is closed. The owners of action items present their progress. Presentations of action items can be performed at the same time a participant has the floor to present his or her progress of project activities.

Project Outlook. The project manager forecasts a 30-day outlook for the project. That is, 30 days from now, will the project be on schedule, within cost, and what is the overall likelihood (high, medium, low) that the project will complete as planned? Although this information initially should be prepared before the meeting, it is likely that it must be altered real-time based on the latest information collected at the meeting.

Schedule Work/Escalation Meetings. The project manager spends the last moments of the meeting declaring what project activities and action items require special attention over the next two to three days. If possible, these meetings should be scheduled now, preferably for the following day. These meetings typically become priorities within the project.

THE MEETING AGENDA should be published and followed throughout the meeting. The project manager has the authority to declare that only a subset of the participants present their plan status, as well as which action items are presented. All status not presented must still be submitted to the project manager at the end of the meeting. This allows the project manager to study the status without subjecting everyone to presentations on other than the currently most important areas of the project plan and action items.

The project manager must lead these meetings so that they run on schedule and are productive. A beneficial technique is for the project manager to assign a scribe to record the meeting notes so that the project manager is free to concentrate on effectively running the meeting. This meeting and its derivative actions serve as the primary driving force behind the project. As these meetings go … so goes the project.

Project tracking is about staying in control–being proactive, not reactive.

by Neal Whitten, PMP, Contributing Editor

THE PROJECT TRACKING MEETING and its derivative actions serves as the primary driving force behind the project. Here are responses to some frequently asked questions about this control mechanism.

What is the primary purpose for project tracking meetings?
Project planning is about getting in control. Project tracking is about staying in control. The No. 1 reason for project tracking meetings is to identify potential project problems before they occur. The No. 2 reason is to ensure that recovery plans are put in place before unrecoverable harm occurs. Project tracking is predominately focused on being proactive, not reactive.

How often should a project formally be tracked?
Project tracking meetings should occur once a week. (The exceptions are small-duration projects that are only several weeks or less in duration, in which case, project tracking meetings could occur more frequently.) Meeting less often than each week can delay the discovery or discussion of serious problems, which can harm the successful outcome of the project. Meeting more frequently than weekly can be quite unproductive and waste scarce time, because it requires members of the project tracking meeting to spend additional time preparing more than one progress status per week. It also requires the project tracking meeting members to spend additional time in meetings rather than being free to work their plans.

Does it matter what day of the week the project tracking meeting is conducted?
Yes. Routine project tracking meetings are very important to the health of a project and require participants to attend-on time and prepared. Therefore, avoid having meetings on Mondays or Fridays; these days are often used as holidays or personal days for extended weekends. Furthermore, meeting participants use Mondays to catch up on progress that may have occurred over the weekend. This leaves Tuesdays, Wednesdays and Thursdays for the meeting. My favorites are Tuesdays and Wednesdays, because I like to reserve the day after the project tracking meeting for work and escalation meetings to address unresolved issues or new issues identified from the meeting. This means that Thursday would be used as the reserved day if the project tracking meeting were held on Wednesday.

What if project members find themselves assigned to more than one project?
If there are multiple ongoing projects across an organization and, referring to the answer to the previous question, all project tracking meetings were held on Tuesdays and Wednesdays, it seems that there would be too many meeting conflicts. However, most organizations seldom experience this problem. In those cases where it does occur, the project managers need to meet among themselves and carefully coordinate their project tracking meetings to avoid such conflicts.

Who should attend project tracking meetings?
Everyone might attend for small projects of, say, 10 or fewer members. For all larger sized projects, a representative from each organization or team would attend. Managers typically should not own activities or tasks and, therefore, are optional attendees. However, the most effective managers will attend as often as they can to support their employees who are assigned to the project.

Is it overkill for the project tracking meeting participants to meet briefly every day?
The weekly, formal project tracking meeting is a must. However, here is an additional technique that can work surprisingly well: The project manager can meet with participants of the project tracking team for 15-30 minutes at the start of each workday to ensure that the top-priority problems are receiving the attention they require. This mostly is an informal meeting that requires little preparation, if any, from the participants.

Any last thoughts?
If you don’t have a reasonable plan from which to track a project, don’t bother having project tracking meetings.

Is your PMO just expensive overhead, or does it provide services with direct benefits to your organization?

by Neal Whitten, PMP, Contributing Editor

LET’S FIRST DEFINE what I mean by a PMO. A project management office (PMO), sometimes called a project office, is a group of people that includes project managers whose mission is to support project managers in the successful launch, implementation, and completion of their projects. This includes performing any tasks that can benefit current or future projects. This mission can be interpreted narrowly or broadly, depending on the budget and overall objectives of a PMO.

Unfortunately, many PMOs are not well received or well respected across an organization. A PMO might be viewed by the organization it serves as simply being overhead, an expensive, bureaucratic fad consuming scarce funding and resources, and providing questionable or weak value based on its costs to the organization. Many times this is an earned reputation! But an ineffectual or unsatisfactory reputation can be turned around as the PMO takes on a plethora of value-added activities.

When a PMO provides services that have a direct benefit to an organization and its projects, a good reputation is inevitable. For example, look at the following starter list of services that a PMO can provide, and ask yourself if such a PMO would be welcomed in your organization.

• Provides well-trained and competent project managers to run key projects (see “Duties of the Effective Project Manager,” PM Network, September 1999).
• Provides project management consulting periodically as requested.
• Develops, documents, and maintains project management best practices.
• Reviews contract proposals from vendors or from within the home organization.
• Sponsors project management education seminars and classes.
• Conducts project culture training (see “Change the Culture in Your Organization … Project by Project,” PM Network, August 1999).
• Performs project reviews (see “Project Reviews-Looking Inside From Outside,” PM Network, May 1999).
• Performs postproject reviews.
• Ensures that new projects are applying lessons learned (see “Are You Learning From Project to Project?” PM Network, March 1999).

The PMO has the responsibility for educating the organization it serves about the benefits it brings to projects, as well as the benefits it brings to the overall enterprise. A PMO must be able to defend its existence. It must create and track metrics that can show the results of its positive contributions. For example, a PMO should survey its customers, both internal and external, on a routine basis to verify that it truly is adding value, and the value is measurable and consistently improving.

The strength and reputation of a PMO rests first with the effectiveness of its project managers. For example, if the project managers are not receiving the proper training, coaching, and mentoring, they will likely be ineffective. If the project managers have a weak mastery of the needed soft skills, then they will likely be too soft to be sufficiently effective (see “The #1 Reason Why Project Managers Fail: Too Soft!” PM Network, December 1997). The effectiveness of project managers can be influenced by the support that they receive from mentors, one another, and the PMO support personnel (see “What Good is a PM Mentor?” PM Network, April 1999). The reputation of the project managers will directly reflect on the reputation of the PMO.

RESIST USING A PMO for implementing activities that provide questionable value to projects and, therefore, to the organization. Be aggressive in defining a PMO that boldly seeks to improve the overall success of the projects and the organization it serves (see “Boldness! You Cannot Be a Consistently Effective Leader If You Don’t Have It,” PM Network, January 2000). The respect your PMO receives over time will be the respect it earns.

The project manager who is not sufficiently technical in his chosen industry can expect to experience a serious handicap.

by Neal Whitten, PMP, Contributing Editor

THE SINGLE MOST INFLUENTIAL person on a project is the project manager. The project manager is ultimately accountable for the successful planning and execution of the project. In this lead capacity, the project manager works with the troops in the trenches-where the real day-to-day work is performed. The leadership exhibited by the project manager will more directly influence and impact more people than any other position … and can profoundly impact the outcome of the project.

As more individuals, organizations, companies, and institutions turn on to the great benefits of adopting project management practices, more people are being placed in project leadership positions without sufficient technical training, mentoring, or experience. A question increasingly being asked today is, “How technical must a project manager be to be sufficiently effective?”

What do I mean by technical? If a project manager is well versed and experienced in the application of project management principles, yet is relatively new to the industry (software development, shipbuilding, commercial construction, aircraft development, for example) where the principles will be applied, the project manager can expect to experience a serious handicap. The project manager will have difficulty with the terminology, the technology, and knowing when and what questions to ask and sufficiently being able to understand the responses. Can the project manager learn? Yes. Can the project manager be highly effective on his first project with this technical handicap? Not likely!

Let’s look at an example: I sometimes ask the participants of software project management classes that I conduct if they think that I would be an effective project manager of a project building the next generation of commercial aircraft. The class participants know that I have 30 years of experience in software development, project management, and leadership assignments. They assume that I am proficient in project management, having, to date, written four books related to the subject. Most participants usually respond, yes, that I would be a good project manager candidate. I would not be a good candidate!

You don’t have to be the smartest, most technically knowledgeable person on the project to be the project manager. You do, however, have to have the knowledge, skills, and experience to be able to recognize when problems surface or potential problems are looming. You must be able to articulate those problems, bring the right people together to solve those problems, and know when the problem has been properly addressed and closed-all this with the proper sense of urgency that the problem requires. With essentially no experience in building aircraft, I would make costly mistakes that an experienced aircraft-related project manager easily would have avoided.

Let’s look at another, but more pervasive, example: Picture a person who is relatively new to both the project management profession and to a discipline, say, software development. Would that person be an effective project manager of her first software development project, particularly one of a respectable size? No! Why? Because, in addition to having weak project management skills, that person would not understand the terminology and technology being employed on the project, such as … What is a reasonable software development process to follow? What are reasonable productivity rates for performing design, code, test, and documentation work? How important are design and code reviews? What testing is essential to perform? … You get the idea.

A PROJECT MANAGER, in addition to having a workable grasp of project management concepts, must also be astute in the technical aspects of the discipline within which these concepts must be employed. If the project manager is not sufficiently technical, then you can expect cost, schedule, quality, and functional problems to occur that would otherwise have been avoided or reduced in magnitude. Training, mentoring, and evolving experience can help a project manager gain the necessary technical skill to be effective. How technical are you?

Author’s note: The project manager must be sufficiently technical. This requirement, however, is far from being highly technical or being the most technical person on the project. It is more a matter of having a sufficient level of domain knowledge regarding terminology and technology that the project engulfs. It also is a matter of demonstrating the leadership to draw upon the technical knowledge and skills from across the project’s membership when needed.

Keep your project focus where it belongs, monitor your priorities daily, and keep your project on track.

by Neal Whitten, PMP, Contributing Editor

I HAVE OBSERVED many hundreds of projects, either as a project member or as an outsider. These projects consisted of from less than a handful of project members to well over a thousand, and project durations ranged from several weeks to several years. My experience has been that the top reason for projects in trouble is that the project’s most important problems are not managed effectively, nor with the sense of urgency they require.

All project members should manage to their top three priorities to make the most effective use of their time. (Actually, it’s the top three to five problems, but the term top three is used for brevity.) Let’s look at an example of how this is performed by a project manager.

First, identify the top three priorities. You probably already know what they are, but if you aren’t certain, then you can do the following. Assemble a small team consisting of project members holding key project positions. (If the project team is very small, then assemble the entire team.) Brainstorm and generate a list of project problems; then prioritize the list of problems based on the importance of them being solved. Truncate the list after the top three to five items, and focus only on what is left, on those at the top. Now assign a person to own each problem, preferably a different owner per problem. Each assigned person puts together a plan to resolve the problem. The plan can be called a priority management plan or a risk management plan. The plan identifies, at a minimum, the following items:

• Who owns the problem
• Activities to be performed to resolve the problem
• Owner of each activity (if different from the owner of the problem to be resolved)
• Dependencies that each of the activities have on other activities
• Duration of each activity
• Special items of note, if any, such as the likelihood of this problem occurring (if it is a risk)
• Persons who must sign off (approve) the plan; these are people with whom the plan has a dependency for it to be successful
• How the plan can be tracked daily.

Each plan must be trackable on a daily basis. (All other project problems are tracked on a weekly basis.) The owner of each of the top problems meets with the project manager at a designated time each day. For example, one problem owner meets in the project manager’s office from 4:00 to 4:15 p.m. each day, another meets from 4:15 to 4:30 p.m., and so on. Meeting each day, even if only for five minutes, shows the sense of urgency that is placed on resolving the problems. Each problem should be closed as soon as reasonably possible.

It is expected that an owner of a top problem is spending most of his or her time each day in solving the problem. If this is not the case, the person’s time on the project is not being used effectively.

As the top problems are worked off the priority list, assign and address the next level of priority problems, and so on throughout the project.

THE TOP PROBLEMS of a project are the areas that can cause the most harm. These problems must be identified, assigned, tracked, and resolved with the urgency they require. The project manager must exercise a great degree of leadership, vision, creativity, and discipline to ensure that the most important problems are being appropriately addressed. If a problem remains on the top-problems list very long, then the owner of the problem, as well as the project manager (if different), are not effectively performing their duties. Do you know your project’s top three problems?

The person who consistently displays bold behavior will far out-perform the person who does not.

by Neal Whitten, PMP, Contributing Editor

PICTURE THIS: You are observing two equally talented and skilled individuals. One person has a consistent performance record of demonstrating boldness, while the other exhibits little or none. What is the distinguishing difference between them regarding their achievements?

The person who consistently displays bold behavior will far out-perform the other. A behavior of boldness helps propel a person beyond what he or she might otherwise achieve. In fact, boldness has such a profound impact on the effectiveness of one’s performance that I find it curious that this trait is not more talked about in the leadership and project management arenas.

What do I mean by boldness? Boldness is the act of responding to a situation in a manner that may be viewed as daring to some, but is essential to effectively address the issue at hand. By boldness, I do not mean being rude, reckless, insensitive, arrogant, or a bully. None of these attributes are acceptable to any of us … ever!

All too often, I hear, “I have all the responsibility, but I don’t have the authority!” This is not true! The problem is that most of us do not take the authority. We do little more than grab the tip of the iceberg in seizing authority, in behaving boldly. For example, when was the last time your boss called you on the carpet for exceeding your authority? It has been my experience that most people cannot remember a time. If you can, and you did nothing illegal or unethical, then you are to be applauded.

Let’s look at some examples of project manager behavior that is essential for achieving a consistently effective performance. This behavior, for many, can require various degrees of boldness. Do you see yourself in these examples? Are you sufficiently bold … or are you too soft?

• Passionately defends the right project plan to the project sponsor, executives, and the client(s). Lead the project team in developing, scrubbing, and professionally defending the appropriate project plan.
• Escalates to higher levels of management-within two workdays-project-related problems that are at an apparent impasse for resolution. Drive critical and potentially critical problems to a timely and satisfactory closure.
• Behaves as if you have the authority to match your responsibility. Take charge as if you own your domain of responsibility, as if you are the true business owner.
• Drives good project management practices throughout the project. Initiate and establish effective project management discipline across a project.
• Asks for help when needed. You will never know all that you will need to know. Deliberately seek out the answers when they are needed.
• Assigns tasks to the appropriate project members. Don’t hesitate to insist that the right project members are assigned to, and effectively working on, problems that affect their domain of responsibility.
• Makes decisions as they are needed; doesn’t delay or abstain. Your timely decisions are crucial to effectively drive the project to achieve its objectives.
• Holds project members accountable for their commitments and actions. Work closely with project members to instill a sense of commitment and urgency in their actions.
• Focuses daily on the top three project problems and their corresponding solutions. Avoid being constantly sidetracked on lesser issues at the sacrifice of working on and solving the most important project problems.

OBSERVE THE PEOPLE around you who are making positive change in their organizations or projects. Their actions require boldness. After a while, you may not think of these co-workers as bold, but simply as effective leaders. However, boldness is an essential element of all consistently effective leaders.