The post is made possible by the great people at Seavus, creators of online Project Management tools such as ProjectOffice.net, Project Viewer, and Project Planner.  Please visit their site for more information.

This article is based on information from one of my favorite PM books – Eric Verzuh’s book entitled “The Portable MBA in Project Management.”

The statement of work (SOW) basically kicks off the project management process and is meant to document the goals and constraints of a project. However, it cannot and certainly should not attempt to document every agreement about the project. There are other project and project management documents for this purpose – requirements, specifications, customer acceptance tests, and also you basic output of agreements and notes from kicking off the project with the customer. The SOW should record the goals and constraints for managing the project. While that can contain a wide range of information, the minimum content listed here gives you an idea of what makes up a good, useable SOW:

• Purpose statement: A clear description of why we are doing this project.
• Scope statement: A description of the major activities of the project in such a way that it will be absolutely clear if extra work is added later on.
• Deliverables: A list of outputs the project will produce, including intermediate deliverables, end deliverables, and deliverables related to project management.
• Cost and schedule estimates: In addition to a budget and a deadline, a description of how flexible the budget is and the rationale behind the deadline.
• Project objectives: The specific, measurable goals of the project.
• Chain of command: An organization chart that spells out who makes decisions and to which superior problems will be reported. It is often a good idea to include the organization chart of the customer, as well.

The SOW is a tool for managing expectations and dealing with change. When disagreements arise after the project has started, they can sometimes be solved by simply reviewing the original SOW. However, it is also true that the original agreements and assumptions may change during the course of a project. In this case, all stakeholders must understand and agree to these changes, and the project manager must write them into the SOW or track them through other project management processes such as change orders. The SOW that remains at the end of the project may be very different from the original document. The amount of this difference is not important; what is important is that everyone has been kept up to date and has agreed to the changes.

Related posts:

1. Is a Statement of Work Really Important?
2. Another Take on the Statement of Work Document
3. Communicating Project Scope

Related posts brought to you by Yet Another Related Posts Plugin.

We’ve all heard the clichés about communication. But putting the ideas into practice is often a lot harder than applying the theories. This is even truer for project management than for departmental management.

For the purposes of this article, I’m looking at department managers who take on the role of project managers for one-off projects or for organizations that regularly rely on department managers to act in the role of project manager, because not all PMs have the ‘luxury’ of focusing solely on project management tasks. Some are temporarily thrust into the PM role while their primary responsibilities – and ultimately skill set – is outside the role of the project manager. We’ll look at the communication challenges faced in these types of situations.

The Communication Challenge

While managing your department, you’re in constant contact with your staff. Their tasks are well defined and recurring. Your people are focused on performance, and their careers depend on how well they execute their tasks. A project, by comparison, is often seen as an intrusion, a departure from the normal routine—even when it’s “normal” to disrupt that routine with a series of projects.

In addition to the manager-team dynamics, you must contend with communication on three other levels:

• The assignment. The executive (or committee) that first assigned the project to you may not agree with your idea of what the project should achieve; or he may change his mind about the outcome wihtout letting you know.
• Other departments. The managers of other departments have their own priorities and may resist your schedule. This usually applies in two situations: when members of their department are on your team or when you depend on that department to supply certain information.
• Outside resources. Your project may depend on help or information from “outside” resources—companies or individuals not part of the organization. These include other divisions, subsidiaries, or offices; a vendor or separate corporation; or a consultant.

Your budget and schedule are your best communication tools. They are useful in communicating with both your team members and outside resources. Each can be used in a number of ways.

The Budget as a Communication Tool

The budget defines the company’s financial commitment, and is used to ensure that project expenses are kept in line. If variances do occur, they often anticipate a scheduling problem as well.

The budget also measures the degree of risk involved with your project. Any change in the company is accompanied by risk, and when time and money are spent, the decision to go ahead is based on a judgment of risk. Management will proceed with the project if it is convinced that the risk is acceptable and that future profit potential justifies that risk. So, for example, when you propose a project, you should communicate in terms of risk and likely reward. Approval will be granted as long as you can convince management that there’s a good chance that future profits will recapture this investment within a reasonable period of time.

The Schedule as a Communication Tool

The schedule defines the project, and, as long as you share it with management, it is a useful tool for ensuring that your definition conforms to theirs. When it’s broken down into phases, with deadlines tied to the final result, management has the opportunity to validate your direction, and you can ensure that your understanding of the project’s goals is correct. At this early stage, you can define exactly what the project should achieve.

You also need to use the schedule during the later phases of your project in conjunction with review meetings to ensure (1) that you are on the right course and (2) that management’s desired outcome has not changed.

Finally, the schedule improves communication with your team, and helps avoid delays. By identifying weak links and by communicating with other department managers and outside resources, you will avoid unexpected problems.

Working with Other Department Managers

For relatively simple short-term projects that are executed strictly within a single department, you, as department manager, have direct control over the time commitments and priorities of each team member.

Because you are aware of your department’s deadlines and workload variations, you can build your schedule around the workload and adjust it as needed. You can also balance departmental and project demands on the basis of your knowledge of each and the scheduling flexibility and control you’re able to exercise.

As the scope of your project grows, your task assumes a greater dimension, and you will begin to work with people from other departments. This is where your communication skills are tested.

A common complaint often heard from other managers is, “You didn’t tell me in time,” regardless of whether problems arise because of deadlines, the use of an employee’s time, or conflicts in commitment. But you can solve most of the problems you will encounter in working with other departments by remembering this key point:

Keep other department managers informed at all times: before and during the project.

By applying a few basic rules for communication between departments, you will be able to defuse the problems that beset all managers at one time or another: territorial motives, power struggles, and—in cases where communication breaks down completely—outright refusal to cooperate. Most of the time, the breakdown of cooperation arises not from a political or personality problem but from a failure in the communication link—especially when you have made the effort to communicate, but only once. People need periodic reminding, so don’t assume that a single message will be remembered.

Related posts:

1. Dealing with Other Department Managers
2. Skills of a Successful Project Manager
3. Communication Weak Links

Related posts brought to you by Yet Another Related Posts Plugin.

The main concept is to capture as much information about the proposed scope change as possible and estimate each task effort that it’s going to take to get there.  Once that effort and budget info is captured here, that information can easily be rolled into the project schedule to show your customer how the change order request is going to affect the overall project timeline.

I’ve been using this version – or at least some variation of it – for most of the past three years on projects and it’s served me very well.  The change order request is always a delicate subject for both the project manager and the customer so handling it carefully and in the greatest detail possible is critical to good decision-making and for on-going customer satisfaction since it usually results in the customer paying more on the project (but not always because even things that decrease the project scope and cost should be documented using this same process….it affects the project, too!).

Again, if you want a Word doc version of the template let me know.  And if you have a version you can share, I’d like to see it and share it with our PM Tips readers as well.

Technical Evaluation
Technical Consultant:		Date:
Conclusions:
Project Manager:		Date:
Conclusions

Budget/Project Impact Evaluation
Project Manager:				Date:
Change of Scope?	Y/N	Description:
Technical Consultant:				Date:
Summary of Work Effort Change:

List of New or Changed Tasks – Projected
Task ID	New?	Description	Budget Hours	Est. Hours	Total Chg	Cost Change
Totals

Risk Evaluation
#	Description	Risk Resolution Strategy

Determination
Approved:		Rejected:		Deferred:
Reason:
TRIRIGA Project Manager:
Signature:					Date:
Customer Authorized Representative:
Signature:					Date:

Execution
Assigned to:		Target Completion Date:
Priority:
Instructions:
Attachment(s):
Completed by:		Actual Completion Date:

Acceptance
List of New or Changed Tasks – Actual
Task ID	New?	Description		Budget Hours		Est. Hours		Total Chg	Cost Change
1
2
3
Totals
Customer Authorized Representative:
Signature:					Date:

Related posts:

1. The Project Change Order Request – Version 1
2. Managing Change on an IT Project: Part 1 – Identifying Change
3. The Project Resource Request

Related posts brought to you by Yet Another Related Posts Plugin.

The idea is that you lay out the formal process of how you will go about procuring things for the project throughout the engagement.  In this document, you identify formal processes for vendor selection, customer/vendor responsibilities and contact info, how the selected vendor will be managed as the procurement is taking place and who’s responsibility that will be, etc.  Laying these formal processes out in advance will definitely help the engagement move along more smoothly and will help you to address this issues as the arise.

PROJECT PROCUREMENT PLAN

[Save file name as: client name PROCUREMENT PLAN yyyymmdd]

PROJECT DESCRIPTION

Provide a brief description of the project objectives and overall performance of the work to be performed.

PROCUREMENT DEFINITION

Describe, in specific terms, what items will be procured and under what conditions.

CONTRACT RESPONSIBILITY

Provide list of project stakeholders who are authorized to enter into contract agreements of purchase for the Project.

VENDOR SELECTION

Describe what steps the project team will take to select a vendor (e.g. RFI, RFP)

DECISION CRITERIA

Describe any known risks which will need to be addressed with the project statement of work.

CONTRACT TYPE

Document which types of contracts will be used and what actions need to be taken to initiate procurement.

CONTRACT STANDARDS

Provide the standards for documentation that will need to be initiated and maintained for each contract.

VENDOR MANAGEMENT

Describe what steps the project team will take to ensure that the vendor provides all of the products and/or services (and only the products and/or services) that were agreed upon, and that appropriate levels of quality are maintained..

ASSUMPTIONS

Describe the initial assumptions under which the project will be to perform.

CONTRAINTS

Describe the scope/cost/ time/resource constraints under which the project will be to perform.

IDENTIFIED RISKS

Describe any known risks which will need to be addressed.

APPROVAL

IN WITNESS WHEREOF, the parties have agreed to the Procurement Plan on the date or dates indicated below.

CLIENT APPROVAL

________________________________

Client Signature

VENDOR APPROVAL

_________________________________

Vendor Signature

Related posts:

1. The Project Charter Document
2. The Project Disaster Recovery Plan
3. The Risk Management Plan

Related posts brought to you by Yet Another Related Posts Plugin.

I ran across a great document put together by Terrence Gargiulo for Makingstories.net. Mr. Gargiulo discusses what he feels are the top ten strategies for managing mobile workers. His full document is a very good read because he also discusses things such as risks and issues to consider when managing mobile workers.  You can access his full document here.

I’m sharing this here because so many times as project managers we are overseeing the work of a very geographically dispersed team. In the past three years I’ve only managed one project with a team that I could see on a daily basis. Dozens of others involved remote workers all around the country.

Here are Mr. Gargiulo’s Top 10 Strategies for Managers of Mobile Workers as described in his document.

Top 10 Strategies for Managers of Mobile Workers

1.    Focus on building relationships

You are now in the business of managing relationships. Once a quarter audit your time. How much time are you spending engaged in activities meant to foster stronger relationships with your mobile employees? Rate each relationship on a scale of 1 to 10 where 1 is weak and 10 is very strong. Craft a strategy for continuing to develop your strong ones and triage the weak ones. Ask yourself why they are weak and what you can learn from them. Avoid finger pointing and hold up the mirror to reflect on your own opportunities for improvement. Extreme cases of under-performance do not warrant time or effort. These however are few and far between.

2.    Streamline communications

Consolidate and prioritize communications. Use email and IM (instant message), texting, blogging, threaded discussions, etc. for relationship-driven communications (i.e., staying in touch and being personal). Communications of an important nature should be cohesive and never delivered in fragmentary pieces that have to be cobbled together by the receiver. Mutually assess the communication preferences of yourself and your team members to develop a communication plan. Avoid assumptions and revisit your plan on a regularly basis especially when the nature of the work is about to change.

3.    Incorporate less didatic forms of communications

Determining the right amount of detail and when to provide detail is an ongoing responsibility of a manager with a mobile worker. As a general rule, less is more. This leaves bandwidth for the times when lengthy, explicit instructions and information are essential for the work at hand. Try working with more story-based forms of communications. Sharing tidbits from the field and office in the form of stories, anecdotes, case studies (use cases), jokes, innocent productive gossip, and even metaphors will relay context, encode key pieces of information, and give mobile workers a sense of inclusion.

4.    Spend more time listening

Obvious, but counterintuitive. When you are out of easy reach and you are tasked with managing the performance of others it’s easy to get sucked into the trap of needing to transmit lots of information. In most cases the opposite is what is most productive. Make listening a priority. This is the hardest and most tiring aspect of managing others. It is also the single most important thing you can do accelerate the development of strong relationships. Listening is not enough. Keep an open mind. Be present and try to enter the perspective of the speaker. This will help you ask effective questions and identify what direction to go with your own needs and agenda. You’ll be surprised at what emerges.

5.    Let mobile workers define communication and reporting practices they want to follow

Structure is critical. Adopt rules of engagement that place people at the center of their own decisions. Managers provide the boundaries and constraints but let employees define the working and communication styles, tools, and processes that will help them perform at the best. Set expectations on two fronts. First, treat these employees’ defined practices as privileges that can and will be modified if key performance metrics are not hit. Second, let employees know there will be times when a projects or work require less flexible, employee-driven communication and reporting practices.

6.    Manage deliverables, not activities

Lots of project-oriented work is well suited to mobile workers. Even roles that are more task driven can be effectively managed if they are broken into deliverables. For mobile workers this may mean collapsing some of the activities of a business process or workflow that had manual checkpoints and controls associated with them into deliverables. Automation where possible can be used or batching activities into larger groups can transform task oriented jobs into deliverables. Realize that there can be many facets of people’s jobs that need to be adjusted to accommodate a mobile work style.

7.    Engage in more frequent and informal performance management activities

When you manage mobile workers, relationships are at the heart of your job. Performance management does not need to be a loathsome, “administrivia” obligation. Designing some unstructured, informal ongoing dialogs with mobile employees about their performance goals and personal development plans is a great way to strengthen communications, and shows an active interest in employees and relationships. This might look and feel very different from one employee to the next. This is another tangible way managers can adapt their style to match the needs and preferences of employees. It works best when the performance management conversation flows in both directions.

8.    Give complete trust until given a concrete behavioral reason to do otherwise

According to a recent survey conduct by HR.com and ic4p, listening and trust are the two most important factors to virtual and remote teams. Without trust, relationships are bankrupt. Abuses of trust can always be found but these occur in spite of whatever systems we put in place. Mobile workers thrive when managers give them complete trust. In some respects managers of mobile workers have no other choice. Use trust to create strong relationships. When some concrete behavior and not just someone else’s word of mouth shows that trust has been violated, then take it away, but not until then.

9.    Use adaptive management styles tailored to individual workers

Every employee is different. Mobile workers make it easier for managers to take a more personalized approach in how they work and interact with members of their team. It takes more work and effort on a manager’s part but the results can be phenomenal. Understanding what enables each employee to perform at his or her best is the most important responsibility of a manager.

10. Leverage technology

Technology drives and supports managing mobile workers. Using technology well is not as simple as it appears. Standard models of communication and transaction should not always be mapped in a simple one-to-one way. Communication and collaboration technologies offer new and exciting models. These need to be purposely exploited in order for organizations to realize the full extent of benefits these wonderful new capabilities and features offer.

Beyond email, IM and phone, Web conferencing plays a key role in virtual team enablement. Take an inventory of “stuff” you need to collaborate on with your virtual team. If the list includes Word docs, spreadsheets, software applications, or anything else on your desktop, Web conferencing will be critical for collaborating in real time. You’re projects will lag if you can’t be on the same page with mobile workers.

Related posts:

1. Equipping Your Mobile Project Staff – Part 1
2. Technology as a Change Agent
3. Proactive Steps to Keep Your Business Running Smoothly

Related posts brought to you by Yet Another Related Posts Plugin.

As I stated in The Project Charter Document article, if our readers have samples or templates they’d like to share, I’ll be more than happy to provide alternate versions of documents that I’m including here or examples of documents that I’m not covering…either will be much appreciated.  And I’m also very willing to send along Word doc versions of these templates to anyone who asks…just email me.

Here I am presenting a template for a Business Case Document.  If your customer is external, you may never see this or may never be involved with it.  If your customer is internal, it’s very possible that you’ll not only see it, you’ll be asked to help create it.  The key is to try to justify the existence of the project and the work to be performed.  The best way to do that is to show some cost/benefit analysis or return on investment (ROI).

This doesn’t have to be an extremely detailed document – leave that for the statement of work (SOW) and, of course, for requirements documents.  It does, however, need to speak very well to executive management and the key decision makers if there is to be any hope of kicking the project off.  Someone, somewhere, makes the final decision on whether or not to throw $$ and personnel resources at this effort and this document needs to convince them to approve that effort.

PROJECT BUSINESS CASE

[Save file name as: client name BUSINESS CASE yyyymmdd]

PROJECT DESCRIPTION

Provide a brief description of the project objectives and overall performance of the work to be performed.

SOLUTION

Describe the proposed solution.

COST MODEL

ROI SUMMARY

Describe when the break-even point of the project will occur and expected annual revenue generated by the project.

PROJECT RISKS

Describe risks that may impact the cost/benefit of the project performance.

Related posts:

1. The Project Business Case
2. The Project Charter Document
3. The Project Change Order Request – Version 1

Related posts brought to you by Yet Another Related Posts Plugin.

I was recently reviewing articles that I’ve written about successes and failures of Project Management Offices (PMOs) and some of the things that make that success or failure happen. I started making a list of these items and thought it might be helpful to share that info with the readers here on PM Tips again in this very condensed format. Remember, these are just my opinions that I’ve expressed in some of my articles along the way.

For PMO to be Effective:

• Director must be a key role in the organization
  • Must have backing and support of executive management
• Director must champion the efforts of the PMs
  • Don’t take credit for their actions
  • Provide ongoing support
  • Assist on critical/visible projects
  • Help breakdown resource acquisition barriers
• Director must run the PMO, not many projects
  • Project focus for the director should mainly be on the highly visible projects where exec decision-making is going to be needed on a regular basis or the business is extremely critical to the organization
  • Organization must value the PMO enough to ensure the director is not bogged down too much to be a successful leader

PMO Promotion

It is the responsibility of the PMO leadership to properly promote the PMO and help ensure its viability and visibility. Its viability is maintained by doing the following:

• Implementing proper and repeatable processes to consistently and successfully manage projects
• Implementing consistent templates for managing project and reporting status to customers and executive management
• Hiring competent, experienced Project Managers to lead projects for the organization
• Implementing proper compensation plans to retain good PM resources
• Implementing adequate training and on-boarding programs and processes to ensure that PMs are well-trained and up to speed on the PMO processes and practices

The PMO’s visibility is maintained by doing the following:

• Reporting project portfolio status on a regular basis and in a meaningful and useful format so that executive management realizes the PMO’s value
• Implementing solid PMO practices to ensure that the high-visibility customers are happy and referencable and the high-visibility projects are successful
• Inviting executive leadership to regularly attend weekly PMO meetings and sit in on project status meetings for the critical, high-visibility projects
• Managing project budgets thoroughly and reporting budget status up through executive leadership to show bottom-line PMO and Project Manager value

The PMO Director, as the leader of the PMO, must be a strong leader with pull inside the organization to ensure that these things happen. Otherwise, the PMO runs the danger of becoming obsolete or, at the very least, insignificant…and the mission critical projects will pass right by the PMO to special teams outside the PMO’s jurisdiction. Executive leadership must see value and ensuring that happens begins with the PMO leadership.

PMOs fail usually for one of the following three reasons:

• Lack of strong, focused leadership
• Lack of repeatable process
• Lack of executive leadership support

Five Signs Your PMO is not Meeting Your Organization’s Needs:

• Executive Management is not Included in the PMO Process
• Training Plans are Non-Existent
• Common Templates and Processes do not Exist
• Poor Upward Project Reporting
• Major Projects Circumvent the Process

All successful PMOs feature four basic components:

• The right processes
• The right tools
• The right people
• Executive level organization support

You can always hire different people. You can bring in consultants to help define better processes or identify better tracking tools. But without the executive-level support, none of it will happen or at least it won’t succeed.

Successful PMOs make an impact on organizational success by performing the following tasks:

• Aligning project delivery with strategic business goals and priorities
• Requiring that every project have an effective PM
• Implementing an appropriate PM methodology
• Consistent management and oversight of the project portfolio
• Obtaining and maintaining company leadership support

Related posts:

1. How to Make Your PMO More Visible
2. Does a PMO Help Ensure Project Success?
3. April 2010 PMO Effectiveness Survey Results

Related posts brought to you by Yet Another Related Posts Plugin.

I’ve already written a lot about customer indecision, change orders, and the customer’s inability to truly know what it is they want. And I’m sure I’ll write considerably more on the topic as it is one of the most critical issues we deal with and our ability to manage these situations is often directly tied to customer satisfaction. It’s our job as project managers to drag that out of them and to anticipate what some of their unstated needs are along the way.

Even though I’ve shared many of my own thoughts on this topic, I still find that it’s interesting to present other view points and text giving different angles on the same popular topics. Most of the text from this article comes from the book “Integrated Project Management” by Earl Hall and Juliane Johnson. This is subsection of their chapter on project change and deals with the how to handle customer indecision and changing requirements. It’s a little dry, and I think it underestimates the amount of changes that PMs must deal with in the course of an implementation, but fundamentally it’s pretty sound.

Management of Customer Indecisions

A project manager must begin working on a project with the expectation that the customer will request change at least once, perhaps several times, regarding the project outcome(s). The project manager must be prepared for the possibility that a task leader or an external subject matter expert will discover and present a new or better way to perform tasks after the completion of the task list. If the proposed change occurs during the project planning period, it can be accommodated by backing up the planning process and replanning with the change(s) in mind. Before this is done, however, the project manager must create a new, revised specification statement and clear it with the customer, appropriate subject matter experts, and key team members. The project must always be working toward one clear goal, and all prior specifications must be destroyed.

Change requests that arise during the project’s planning process are not hard to deal with if they are few and infrequent. Changes do interrupt the planning process and cost time and money, but aside from that and the frustrations the team experiences, they can be handled effectively. When a customer is uncertain about exactly what he or she wants and frequently changes his or her mind this must be dealt with as a special case.

Customers often want a project to begin before they have decided on a precise outcome. They may not expect to be able to precisely define what they want for some time. However, integrated project management (IPM) is based on the premise that a precise outcome statement—specification—must be decided upon before planning can begin. Both experience and logic support this proposition. Nevertheless, when thinking is at the scope level, it is often reasonable for the customer to be uncertain of the precise outcomes. Can an integrated project be started under these conditions? The answer is yes. A preliminary specification can be created. A project manager begins the project by leading the creation of this specification.

As the project manager helps migrate the project from scope to specification, he or she aims for a precise specification that will capture the current best estimates of what the outcome should be. This specification will be used in the initial planning and execution of the project. At the same time, the project manager puts in place a project specification change procedure to deal efficiently with the outcome changes the customer may desire later on.

Experience has proven that this approach is more efficient than simply starting in a general direction, then adjusting, redirecting, and reorganizing as an outcome concept emerges. It must be understood that in IPM, replanning will be a major event and will not take place piecemeal. It will not occur often during the life of the project. Small and frequent modifications of the specification must be prevented because such practices kill projects.

The rationale for insisting on the creation of a specification before starting project planning derives from the processes that must take place when the change in a project is executed. Before a project can be changed, there must be something to change. The effort to get the customer to agree on what the “current” best estimate of what the outcome should be is defined within the statement of work. Sometimes, customers do not decide on exactly what they want until they see what is involved in providing them with what they think they want. Sometimes, the general dimensions of an outcome are identified, but the exact characteristics of the outcome must wait on “research in progress.” The customer and the project manager agree that a precise outcome definition within the general framework of the expected outcome will enable the project manager to begin the project planning. It also will provide for the startup of project execution. The initial plan is expected to be relevant when the revised outcome statement is decided upon.

Creation of the initial project plan gives the project team something useful to do now, and it creates a good plan for the team to examine and change when a specification revision is presented. This fits in with the fundamental process of project change. When a change is proposed, the original project plan—the Gantt chart and the resource table—is the necessary reference for the considerations of what can be done and what this will cost.

Related posts:

1. Is Project Planning a Task?
2. Dealing with Unreasonable Customer Expectations
3. Negotiating for Specifications and Resources on the Project

Related posts brought to you by Yet Another Related Posts Plugin.

In Part 1 and Part 2, we covered the first six critical questions listed below that should be addressed when closing out any project. In the finale, Part 3, we’ll cover items seven through nine highlighted in bold letters below:

• Have all the project objectives been achieved?
• Is the client satisfied with the overall project?
• Have the necessary post-project support agreements been established?
• What were the major concerns with the project?
• What are the key lessons learned from the IT project?
• What would you do differently?
• Do you feel the solution was cost effective?
• When would it be applicable to enhance or update the delivered solution?
• What is your executive leaderships view of the project outcome?

Do you feel the solution was cost effective?

Here’s your chance to analyze the solution in words in financial terms. And we’re not really talking about budget here, but that’s a big part of it. In hindsight, did the engagement:

• Utilize the best level of resource skills and thus use resources in the most cost effective-way possible.
• Should Phase A really have been implemented first as the customer required, or would it have been a more sound business decision, in your opinion, to implement Phase B first?
• Is the final solution meeting the customer’s needs in the most cost effective manner possible? Would certain enhancements or different requirements have resulted in a more cost effective solution?

The list could be long, but I think you get the picture. Ask yourself the tough questions and imagine this isn’t for the customer to see. In fact, imagine you ARE the customer on this one but also have your additional insight.

I’m not saying you can’t involve the customer on this one – you certainly can – or you can perform it separately with your team and then with the customer and compare results.

When would it be applicable to enhance or update the delivered solution?

You’ve probably had an eye to the future all along and you’ve probably already discussed some key points along the way with the customer – especially if the project was a successful one and the customer satisfaction seems high. That’s what a good project manager does.

Think about ways you can provide new and future services to this customer and certainly keep in contact with them post-implementation on future product capabilities that you feel they will want or can benefit from.

What is your executive leaderships view of the project outcome?

This one is important to your career. No question about it. How does your leadership feel about the project? This likely will come more from leadership’s discussions with the customer than from your discussions with the leadership. And it should.

If it was a visible, critical project, you know that they’ve been in communication with the client along the way and if anything has gone wrong, they’ve heard about it. They’re not as likely to hear about the successes, but if you think the project has gone well, encourage your CEO or other leadership to follow-up with the client and discuss the outcome with them.

Summary

We’ve covered what I consider to be nine key questions to review once your project has been implemented. Most are for you and your team, some should also include the customer. But be sure to perform some sort of post-implementation checklist like this. You’ll benefit from it as a project manager, your team will benefit from it in learning what went right and what went wrong, and your organization will benefit from it – especially if you can share the successes and the lessons learned with others in the organization.

If you have other key points or questions to add, please comment.

Related posts:

1. Closing Out the Project – Part 2
2. Closing Out the Project – Part 1
3. Managing Change on an IT Project: Part 3 – Implementing Change

Related posts brought to you by Yet Another Related Posts Plugin.

In the finale of this three-part series we will look at further at Jason Chravat’s presentation of the attributes of a project manager from his book entitled “Project Management Nation: Tools, Techniques, and Goals for the New and Practicing IT Project Manager.”

In this segment, we’ll discuss the need for the project manager to be able to:

• Make timely and critical decisions
• Effectively select and manage a team of skilled IT resources
• Have a professional approach when dealing with management, the team, and the customer

Ability to Make Decisions

An important attribute of any project manager is the ability to make decisions on a project. In meetings, project managers are often challenged to make decisions that are crucial in moving the project forward. If the project manager cannot effectively make decisions, the project surely fail.

Ability to Select and Manage a Project Team

It is important that the project manager be able to draw up a preliminary list of people who will be needed on the project. He or she can be do this by selecting those individuals who are available within the organization and who possess the relevant skills and experience required by the project. The project manager should be able to guide and initiate the external hiring process for those team members who are unavailable. Key factors or selection criteria that should be kept in mind when selecting team members are:

• Candidates have the skills and expertise for the project
• Candidates are available to remain for the full duration required on the project
• Candidates are team players
• Candidates are results-orientated and can set goals
• Candidates are optimistic about the project and outcome
• Candidates are trustworthy
• Candidates are able to work on multiple tasks in isolation

Remember, once the project manager has selected the team members,the success of the project will depend on the manager’s ability to keep the team focused, optimistic, and committed to achieving the overall project objectives. However, it is not uncommon for personal problems to arise while working on a project, and the project manager should be able to identify many of the symptoms ahead of time. The project manager should have the experience and ability to work with all people, irrespective of any individual’s race, religion, nationality, age, or gender. The project manager and the individual should immediately deal with any conflict that arises, and the manager should use the most appropriate course of action to resolve the problem. Additionally, the ability to praise and recognize the project team is important. It is essential that when the team has worked hard to meet objectives, often under difficult circumstances, that they are awarded the recognition.

Having a Professional Approach

Project managers should want to be considered as professionals. The status affects the quality of life for all people on the project, organization, and even in society. Therefore, it becomes vital that a project manager conducts work in a professional manner in order to earn and maintain the confidence of team members, colleagues, employees, employers, clients, and the public. The following is a code of ethics that project managers should use to help maintain their professionalism:

• As project manager, I will strive to maintain high professional standards in the preparation and delivery of my projects, and I will be held accountable for the success or failure of those projects.
• Regarding the actual work aspect of my project, I will strive to provide the leadership, trust, tools, and support to ensure all projects are completed on time, within cost, specification, and to my clients’ requirements.

Professionalism refers to being able to encourage respect and honesty in all business-related matters and during the course of any project. It is important that project managers ensure that all client or employer information be kept confidential and not lead to a situation where there is a conflict of interest.

Project managers also have a duty to their respective communities, by ensuring that no project be implemented in any location where it could possibly place lives and property at risk. An appropriate quotation from one of history’s famous project managers can be used to describe ethics.

The general must be righteous. If he is not righteous, then he will not be severe. If he is not severe, then he will not be awesome. If he is notawesome, then the troops will not die for him. Thus righteousness is thehead of the army. —Sun Tzu

Related posts:

1. Attributes of a Successful Project Manager – Part 1
2. Attributes of a Successful Project Manager – Part 2
3. Project Communication Series: Customer Interfacing

Related posts brought to you by Yet Another Related Posts Plugin.