Project Management from a Distance – Intro

In this upcoming six-part series we’re going to look at and discuss everything about being a remote project manager. For the most part, it will likely apply to other members of the project team. I’ve made little secret of the fact that I believe remote project management is good, is practical for many situations, is green, and can be very rewarding. However, it must be done by the right individual with the right intentions, under the right conditions and for the right reasons.

The Six-Part Series Overview

Over the course of six articles, I intend to cover the following topics (however, I make no guarantees that I won’t shift course, remove parts or add parts depending on how the discussion is progressing):

Part 1 – Why remote?

Part 2 – Will it work for you?

Part 3 – What type of job enables remote PM?

Part 4 – What setup do you need?

Part 5 – Negotiating when it’s not an obvious move

Part 6 – Staying the course

Recognizing that remote work is not in everyone’s interest level and it’s not for everyone, I’d like to cover these topics in order and get feedback from readers on their own thoughts and experiences. It’s not a secret that this economy lends well to creativity in the workplace – it’s often necessary to stay employed and for companies to keep as many employees as possible.

In the coming articles, we’ll examine why you should work remotely (both from the employee viewpoint and from the employer), what type of individual and mindset it takes to successfully work remotely, what type of projects work well in a remote management situation, what do you need to setup shop to work remotely, how to go about negotiating a remote situation when it’s not an obvious option, and staying on course and remaining both happy in this type environment as well as relevant in the workplace and to your employer or clients.

Some Interesting Data

Before move any further in the discussion of remote project management – here are some interesting numbers on remote IT workers (source in parentheses):

• 70% said they would rather get their work done on a secure connection even if it meant their work would be late (CIO.com)
• 78% say their IT dept. has provided them with the technology to work remotely on their own PC rather than needing to rely on a company-issued laptop (I personally don’t see this as a good thing) (CIO.com)
• 43% of downloaded personal pictures, videos, or software for their own use on company-issued laptops (CIO.com)
• 25% admitted they’ve visited blacklisted of inappropriate websites on their company-issued laptops (CIO.com)
• 74% said they can’t get their work down without the internet (CIO.com)
• 65% said it would be easier to live without their car for a week than live without the internet for a week (CIO.com)
• 12% admit hacking a neighbor’s wireless connection when necessary (Cisco study)
• 21% allow friends and family to access the internet on their work-supplied computer (unknown source)

These figures weren’t meant to scare anyone away from remote work but rather to inform you of what’s going on in and out of the workplace. Whether you use your own equipment or company-supplied equipment, be aware that you’re responsible for critical data and for the timelines of the projects you manage – be prudent in the way you handle yourself and the resources you utilize.

Closing Out the Project – Part 3

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.

Closing Out the Project – Part 2

In Part 1, we started the process of covering some critical questions to ensure all of the project “i’s” are dotted and “t’s” are crossed. The list can be much longer, but I’m choosing to cover 9 basic questions to look at when shutting down your project. We’ve covered the first three – now for Part 2 we’ll cover items four through six 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?

What were the major concerns with the project?

No matter how perfectly a project goes, there are always concerns. You may have been able to mitigate whatever issues came up, but they still happened whether they knocked your project off course or not.

What we want to do here is document what those major issues or risks were. They key questions to ask during this process would be:

• Was the concern anticipated in advance (meaning was it something your team or customer foresaw as an issue or risk and thus you were already looking out for it)?
• Did the concern end up affecting the project adversely in terms of time, money, resources, or progress?
• Did it affect customer satisfaction and if so, in what way?
• How did you react to the concern and was your action the appropriate one in hindsight?
  

What are the key lessons learned from the IT project?

For this activity, it’s most beneficial to sit down with the customer post-deployment and formally discuss and document lessons learned. This is somewhat similar to reviewing the major concerns in the previous question, though this one is best done face-to-face – or by phone – with the customer as their insight will be invaluable…and is critical feedback to have. As I’ve stated before, your customer may have been unhappy with things and you had no idea – and now will be your opportunity to find some of those things out and understand how to better react in the future.

What would you do differently?

Knowing what went right and what went wrong, how the project turned out and how your customer feels about it, now you can look at what you would do differently in the future. There may even be other opportunities with this customer and having a plan for a different course of action on specific issues that arose on the engagement can be an invaluable piece of information going forward.

Re-review the issues and risks faced on the project and asked yourself and your team – did we react appropriately and, if not, what should we have done differently. Chances are, the issues will show up again in another project and you’ll be ahead of the game. If we don’t learn from our mistakes, we are destined to repeat them.

Next

In Part 3 we’ll further discuss these items in terms of the project closeout checklist/review…

• 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?

Closing Out the Project – Part 1

When you’ve reached the end and deployed the solution, then it’s time to make sure everything has been completed, all paperwork is done, and no stones are left unturned. It’s best to do that with some sort of checklist and I propose using a list similar to this:

• 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?

In Part 1, we’ll discuss the first three items above:

• Have all the project objectives been achieved?
• Is the client satisfied with the overall project?
• Have the necessary post-project support agreements been established?

Have all the project objectives been achieved?

This should be fairly easy to evaluate. Look at the project schedule and review all milestones and deliverables. Have they been met? At this point, we’re not considering timeliness or budget, we’re just concerned with did we hand the customer what we said we would. Did we supply a Functional Design Document, did we provide weekly status reports, was training completed successfully and signed off, was user acceptance testing (UAT) fully completed including re-review of all issues and did we get official signoff, etc.

Though it definitely shouldn’t be the first time during the engagement that you do this – it’s also a very good time to go back to your kickoff session notes and see that all points discussed during that meeting have been addressed. Make sure at this point that the customer knows you’re concerned that you fully covered everything for the project – they’ll appreciate it and it definitely helps with customer satisfaction levels and can increase the chances of repeat business from this customer.

Is the client satisfied with the overall project?

You may think you can simply answer this yes or no based on your knowledge of how things went on the project and the communications you had with the customer along the way – but that is not always the case. On some projects, you can end up being very surprised by the customer’s on viewpoint of their satisfaction levels.

I’ve had customers on projects that went extremely smoothly later state that they weren’t happy about how I handled something or weren’t pleased with one of my team members or how we delivered ‘x’ deliverable. And I’ve had other projects were I was certain the customer was just about ready to ask that I leave the project only to find out that they were very happy with me and with the team and how things were going. They were just demanding and somewhat needed. But we were meeting their needs and they were happy. It’s amazing how off your perception can sometimes be concerning your perception of the customer’s satisfaction level and what their satisfaction level truly is.

Have the necessary post-project support agreements been established?

Usually you’ll move from deployment into a post-deployment with some sort of pre-defined plan to both hand-off overall support to your tech support group but also you’ll agree to make your original delivery team available for a 30 or 60-day window to do immediate fixes should problems arise in the functionality of the delivered solution. That’s something that just needs to be worked out with the customer and something that was likely planned for both by Sales with the customer during the sales process and discussed between you and the customer during kickoff.

Just make sure that whatever the plan is, you act on it. If it’s to keep your team available for 60 days should problems arise, then make sure that every team member knows that and that each of their managers know that as well. It can have an affect on their next assignments, but it must be addressed in advance of deployment.

Next

In Part 2 we’ll further discuss these items in terms of the project closeout checklist/review…

• What were the major concerns with the project?
• What are the key lessons learned from the IT project?
• What would you do differently?

Achieving Stakeholder Satisfaction Through Project Control

This article is another excerpt from one of my favorite Project Management books: The Portable MBA in Project Management by Eric Verzuh.

The project control process is designed to spot problems early, while they are still small enough to correct. It is an iterative feedback loop in which the project manager uses measurement and testing to evaluate deviations from the plan as to cost, schedule, quality, and risk. These deviations may or may not result in corrective action. The key is to monitor closely enough and often enough to spot such deviations before they get out of control. There are five steps in the project control process:

1. Define what will be measured and/or tested and how often. This should incorporate business requirements, cost constraints, technical specifications, and deadlines, along with a preliminary schedule for monitoring that includes who is responsible for it.
2. Monitor progress and evaluate deviations from the plan. During each reporting period, two kinds of information are collected:  (1) Actual project data, which include time, budget, and resources used, along with completion status of current tasks.  (2) Unanticipated changes, which include changes to budget, schedule, or scope that are not results of project performance. For example, heavy rain may delay the completion of a housing project.  Earned value analysis, described later in this chapter, is a useful method for evaluating cost and schedule deviations.
3. Report progress. Keep reports succinct and timely. Do not delay a report until after a problem is “fixed” to make the report look better. Likewise, avoid lengthy reports that delay the dissemination of important information to others in the organization.
4. Analyze the report. Look for trends in the data. Avoid trying to “fix” every deviation. If there is no trend to the deviation, it likely does not require corrective action at this time.
5. Take action where necessary. This includes updating the project plan and notifying any stakeholders who are affected by the changes. If the changes are big enough, they will require stakeholder approval in advance.

Stakeholders Influence Project Control

The factors that a project manager monitors and reports on to stakeholders depend on who the stakeholders are. For example, consider a major upgrade to computer systems at an international airport. Stakeholders on this project include the Federal Aviation Administration and several major airlines. The FAA is concerned most with safety and wants to see data that show the project is meeting objectives to prevent computer system failure in the future. The airlines are also concerned about safety, but they are equally concerned about the amount of airport downtime during the project because they want to minimize the amount of time their planes stay onthe ground. The project manager must monitor both safety, which is the primary objective of the project, and airport downtime, which occurs because of the project itself.

Another example of the influence stakeholders have on project reporting is determining reporting periods. Reporting periods define the frequency that progress is formally monitored and a status report is produced. The size, speed, and complexity ofthe project influences length ofa reporting period, but so do stakeholders. Consider these factors:

• The need for information at the executive level: This information usually relates to big picture questions such as “Will we deliver on time?” or “Are we on budget and on schedule?” Project managers demand and use monitoring information more frequently than executives, but knowing when their superiors expect accurate updates will affect the monitoring cycle.
• New information about activities or schedule: The project schedule will change. As the project progresses, the project team gets a better picture of what is required to complete the project and can, therefore, improve its original estimates. Ifstakeholders dictate an aggressive schedule, more frequent reporting will uncover significant deviations sooner. Because trends are more useful for understanding a project’s trajectory, frequent reporting periods provide earlier warnings that schedule targets may be missed.
• Resource mix: Changes in the quality or quantity of resources assigned to a project can have dire consequences on the team’s ability to complete it on time and on budget. The monitoring plan can allow you to stay on top of getting the right people, materials, and equipment to the right place at the right time.
• Major events: Whether positive or negative, major events can change the assumptions on which the project objectives are based. Many major events that will affect the project are known in advance. These can include the end of a project phase, selection of a major subcontractor, and external events such as political elections. You know the event is important to the project, so schedule time to assess the impact.