Throughout the project, the project manager and the rest of the project team are utilizing these tools to create visual, professional, and hopefully meaningful and useful project documents to give to the customer and show to the organization’s executive management.  In fact, if the project manager is overseeing five or six or even more projects at once, the creation of these documents and files with these tools can end up taking most of his available time.  Especially if accuracy and perfection is a goal – and it should be.

Don’t forget the personal side

What we need to always be aware of, however, is that our customer needs more than just information about the project.  And for communication they need more than daily emails.  It isn’t always about what we can produce for them and how professional it looks.  The project manager must be able to connect with the customer on a more personal level than with schedules, charts, and reports.  In order to maintain the highest level of customer satisfaction, the customer must feel like they are ‘in touch’ with the project and the project team.  That isn’t likely to happen if all they see are emails coming their way with information and professional-looking document attachments.

When we’re busy with multiple projects and many deliverable responsibilities throughout the week on each project we’re maintaining, how do we as the project manager keep it personal with the customer?  Here are a few tips to maintain that close link with the customer even when we’re overloaded with projects:

• Go beyond the weekly status call and reach out by phone to each project customer at least once a week
• Go onsite for key phase kickoff meetings to keep face time high with each customer
• Touch base informally – not just formally – with the customer several times per week via email to ensure they feel like there is always an open line of communication
• Get someone from your executive management team to sit in on at least one weekly status call with the customer so they know their project is visible and getting attention in the company

Summary

The tools we use are great – and running more than one project at a time would be nearly impossible without them.  But we must always remember the personal side of project management – the grass roots customer service side.  To maintain high levels of customer satisfaction, it really is a requirement.

Related posts:

1. Twitter and Facebook as Project Management Tools?
2. Managing the Onsite Team from a Distance
3. Project Communication Series: Project Schedule

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

Some of these potential repercussions can include (depending on the size and visibility of the failure and the reasons behind it):

• Reprimanding or termination of the project manager
• Reprimanding or termination of project team members
• Lost future business with the customer
• Bad press for the organization damaging its reputation
• Bad feedback to other current or potential customers

So how do we deal successfully and proactively with project failures?  When you’re a project manager, even if you’re an incredibly skilled, successful, and lucky project manager you’re going to experience failure at some point.  So we all need to know how best to deal with this impending failure both for our sake and the sake of our team members who we may end up working with again on a future project.

I can’t say I’m always successful at performing these steps and thankfully the failures have been fairly small in very infrequent, but these are the processes that I believe the project manager needs to go through in order to best deal with the project failure in terms of his customer, the project team, and his executive management…

Lessons learned session with the project team

Hold a lessons learned session internally with the project team.  Let them all air their issues.  Better here than in public or in front of the customer.  Many may feel that the failure is the customer’s fault and that can and should be discussed, but aggravations should be aired here, not in front of the project customer or even executive management.

Lessons learned session with the customer

Take what you all discussed internally (tone it down if necessary) and hold a lessons learned session with the customer.  No matter how upset you are or the customer may be, this is still a critical meeting to hold and everyone will learn at least something from it.

Debriefing with executive management

Take the outcomes of your lessons learned sessions both internally and with the customer and meet with your executive management staff.  By now they have their own view of what happened and how they feel about it and how it may affect your PM role long term, so use this opportunity to get your teams views known to everyone.  State your case and how you would now deal differently with the situation.  Offer up a proposed different solution should similar issues arise on future projects.  Think proactively.

Email press release within the organization

If the project was fairly visible, then word has gone around the organization about the outcome of the project.  When projects are successful, often times an internal press release is put out about the success of the project.  I feel strongly that similar information should be disseminated about a project failure – basically to ensure a common understanding in the organization about what happened and to lessen the amount of finger pointing that goes on.  This is also helpful because others in the organization may gain some helpful lessons learned information that will enable them to avoid a similar situation on their projects.

Related posts:

1. Making the Most of a Bad Situation
2. Documenting Lessons Learned
3. The Difference Between Project Success and Failure May be in Your Head

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

The survey is now active and ready for your participation at:

http://www.bradegeland.com/june-survey-part-2.html

In this 2^nd part of the survey, we’ll be looking at the following topics:

Definition of project success

For this question, I’m looking for how either you or your organization primarily defines project success.  Is it on time project delivery, on budget project delivery, or customer satisfaction?  And for those of you who feel it’s something other than those three options, there is a write-in ‘other’ response area available.

Percentage of successful projects delivered

This one will definitely a best-guess scenario because I doubt that anyone has compiled hard numbers on this plus it’s somewhat subjective as to what one would call a ‘successful’ project.  I’m trying to get an idea of where our readership stands in regards to successful vs. failed projects.  Recent studies – as I’ve reported here in recent articles – place the percentage of failed projects between 62% and 75%.  It will be interesting to see where PM Tips readers fall in that spectrum.

Percentage of project revenue from change orders

Change orders are always a love – hate thing.  For the PM and team, they are a great way to increase project revenue and executive management loves them.  However, it’s often difficult and even uncomfortable for the project manager to present the customer with change orders – unless they are the result of direct customer requests.  Also, change orders are a necessary tool to bridge the gap between the originally defined requirements and what reality fleshes out over the course of the engagement.

Weekly communication responsibilities of the project manager

Finally, I’m interested in finding out which regular project communication tasks that should be happening on a weekly basis are actually happening.  This can come from anyone on the project – not just the project manager.  But it will be interesting to see how many of these regular communication tasks are actually happening regularly.

Again, Part 2 of the June PM survey is available here:

http://www.bradegeland.com/june-survey-part-2.html

Thanks again – please check back later in June for results of Part 1 and Part 2 of the project surveys.

Related posts:

1. June 2010 PM Survey Results – Managing the Project
2. June 2010 PM Survey: Managing the Project – Part 1
3. March Survey – Remote Project Management

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

I have to believe that British Petroleum (BP) actually is treating this issue like a project, but I’ve never seen so much back to back failure in any project I’ve ever managed or witness from a distance so it’s truly hard to believe that PM best practices are being applied to this one.

Here are the facts we have so far:

• Oil has been flowing freely for 46 days so far
• A low end estimate of per day oil flow is 210,000 gallons
• That’s 9,660,000 gallons spilled over the 46 days
• The White House has just sent BP a $69 million bill for cleanup efforts

These numbers are amazing and shameful all at the same time.  And there’s almost no end in sight due to BP’s repeated failures to make progress on capping the well.

Questions we have to ask?

• Did BP do on-going risk analysis?
• Have laws been broken?
• Should any BP executives still have their jobs when this is finally over?
• Do you think the BP Project Manager will ever get another gig?

This may not be the case, but each new attempt to cap the well or channel the oil flow to a surface ship seems to be a new shot in the dark and continually ends in failure.  It’s easy to say that customer confidence is at an all time low right now for BP.  Each new attempt needs to be treated as a separate project – or at least a separate sub-project with planning already in the works for the next attempt.  Potential issues need to be reviewed, risk analysis and risk mitigation discussions need to be happening 24/7.

As a US citizen and taxpayer, I’m continually frustrated to hear that “this attempt may work, but it’s never been tried at this depth before.”  Every time I’ve heard that, it’s resulted in failure.  What about testing – are they performing any testing whatsoever?  I’ve never run a project from the hip like this and no project should be run as blindly as the BP oil spill project has been run so far.

I understand that 46 days ago – when we were still back at Day 1, BP was concerned about the lives of the workers on board the rig.  And at the same time they wanted to stop the flow as quickly as possible and probably thought they could.  But 46 days later we know how wrong that thinking was.

Best practices project management says do a good job defining your requirements and spend the right amount of time up front planning your project before beginning the engagement.  That clearly didn’t happen here – at least not with the right people involved.

Related posts:

1. Eight Things Your Business Analysts Need to Know
2. Common Project Issues: R & D – Too Much “D” and Not Enough “R” – Part 1
3. What if…There was No Project Management?

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

In terms of surprises, in my opinion there were four key surprises that I will describe in my run down of the results below…

Formal PM Methodology

Here’s the first surprise: only 53% of the survey responders indicated that their organization followed a specific project life cycle or project management methodology.  That means that 47% are basically ‘winging it.’  While that’s ok on occasion, it’s very difficult to realize long term organizational and project success without some sort of consistent, repeatable process in place.  Nearly half of our survey responders don’t have that and that’s concerning.

PM Software

No big surprise here … 58% use Microsoft Project as their primary tool for managing projects.  What was surprising is that a full 26% are not given any specific tool to use when managing projects.  Back to the ‘winging it’ concept… not good.  11% indicated that they utilized a web-based PM tool and 5% indicated that they use some desktop tool other than MS Project to schedule and manage projects.

Smartphones

When asked if their organizations provided them with smartphones for managing calendars, email, and contacts with, a full 68% indicated that these are not provided.  That is surprising to me.  That number may be skewed by independent consultants responding as often they provide their own equipment, but I still find this to be a very high number of negative responses.  Only 32% indicated that they are provided with smartphones as a tool.

Laptops

When asked if organizations provided project managers with company-issued laptops, the overwhelming majority said ‘yes.’  Indeed, 79% of responders indicated that they have been issued laptops by their organizations.  Only 21% indicated that they were never issued laptops.  I find that 21% number somewhat surprising in this day, but it’s not one of the four key surprises that I mentioned earlier and it may again be skewed somewhat by the independent consultant who often is responsible for their own equipment.

Travel

Finally, the travel question – which really doesn’t have much to do with equipping the project manager.  I was just curious on the amount of travel that is required of our PM readers.  And when companies are putting PMs and project professionals on the road, it’s important that they are well equipped to do their jobs.

This one was very surprising to me – mainly because a lot of PM jobs indicate 25-50% travel.  I’ve been in those positions and that amount of travel has really never panned out – it’s always been much less.  So it’s surprising, and good to see, that our readers match up well with that.  84% indicated that they travel only 0-10% of the time.  5% indicated they travel 11-25% of the time.  11% are required to travel approximately 25-50% of the time.  And no one responded that they are required to travel more than 50% of the time.

Summary

Overall, I would say that our PM readers are moderately equipped to do their jobs.  They have the computer hardware, for the most part, but they are lacking communication devices to tie everything together and they are sadly lacking in consistent, repeatable PM methodology and processes to run their projects successfully.

That said, if your organization is lacking a good project management life cycle or methodology, (get ready for a shameless plug) you may want to check out my book that I will be making available hopefully later in June as a PDF.  It’s titled, “RealPM: A Hybrid PM Methodology for Real Life IT Project Management.”  For more information, go to here.

Related posts:

1. May 2010 Survey: Equipping the Project Manager
2. February 2010 PMP Survey Results
3. July 2010 PM Survey Results – The Project Schedule

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

Now, take that scenario a step further and imagine what happens when your project team – or at least most of them – are onsite at the customer location either working an issue, kicking off a new project phase, or performing a necessary task, and you can’t be there.  It happens, but it can also put a strain on the project and team – and even the customer.  Maybe there’s no room in the budget for everyone to be there and as the PM your services are not as critical as the others right now.  Or, more likely, you’re booked on 4-5 other projects and one or more of those are requiring your time – or face time – and you simply can’t be in two places at once.

So what actions can you take to keep the team in check, keep the customer satisfied, and keep the project moving forward on the right track when your team is there and you can’t be?  Here are a few tips….

#1 – Don’t waver from the weekly project schedule

Consistency is very important – especially in the eyes of your customer.  Customer perception is huge.  If they see that, even though you’re not there, everything is still happen as it always has … that it’s basically business as usual … then they won’t be concerned.  Have the weekly project status meeting at the same time as always, deliver the weekly status report at the same time it always has been delivered, and definitely keep the project schedule updated and delivered to the team and customer on the same schedule that you always do.

#2 – Increase internal team calls

I’ve written a lot about remote teams and remote project management.  So you may be asking …. “This is still a remote PM situation, why the change in internal team call frequency just because the team is onsite and you’re not?”  Good question.  It’s because the team is there representing you and the entire project and you are not.  It’s not just about maintaining status, it’s also about keep the project team in check.  It’s so easy when you’re onsite to give the customer too much detail.  That detail can either make a customer nervous, drive them crazy, or give them information they’re not prepared for yet.

A daily call – even if it’s brief – will keep the communication lines open and will ensure that you have the information you need to maintain that communication with the customer.  Your team should not be doing it.

#3 – Add a one-on-one PM to customer call

While the team is onsite and you’re not, have a few calls one-on-one with whoever is leading the project on the customer side.  The calls can be daily or maybe 2-3 times per week, but have them.  That way the customer understands you’re involved and they can forward on any concerns to you that they might otherwise keep quiet with the rest of your team sitting physically in the same room with them during the weekly status calls.

#4 – Increase your reporting to executive management

Finally, increase your upward project status reporting to your executive leadership.  They know your team is there and you’re not – for whatever reason.  Let them know that you’re on top of things and in frequent contact with the team and the customer.  Let them know what’s happening on the one-on-one calls with the customer.  They need confidence builders just like the customer does – and this is good for your career.

Related posts:

1. Project Management from a Distance – Part 3
2. Project Management from a Distance – Part 2
3. Project Communication Series: Project Schedule

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

It was interesting to find, when attending a session at Interop 2010 in Las Vegas last month, that a handful of executives from different organizations sitting on a discussion panel on cloud computing all had basically different information and views of what cloud computing meant to their organization.  And they definitely had varying degrees of successes and frustrations during and after implementation.

At the end of the day, cloud computing may still mean different things to different people.  As of now, there are a variety of things that you can do to actually be computing in the cloud and utilizing cloud services.  However, for the project manager or IT consultant, until the industry is able to get a better handle on what those cloud computing services really are and how far reaching the organizational benefits are, it may still be a hard sell with our customers.  The keys being security, data safety, and data access.

I’ve discussed the possibility of incorporating cloud computing practices in the organizations of some of my clients and the push back I regularly get is “will my data be safe?”  The quick answer is yes, but the real answer is almost an “I don’t know” or “it depends.”  And the next question is “will I have access to my data if my provider has a disaster?”  That one is a little more out there … a little more unlikely.  But it is certainly a key question and one that every CEO or CIO should be able to get an answer to.  That’s the one that must go straight to the provider – and one that a recent poll showed that many providers are not quite yet equipped to fully answer.

This is basically an opinion article.  I think we’ll get there, but I still feel we’re a couple of years away from really standardizing what our IT cloud computing offerings are, what the full benefits will be, how our data will be safe, protected, and secure, and what happens in times of disaster when data access becomes increasingly critical.

Related posts:

1. Data Security and the Cloud it Rode in on….
2. Defining the Cloud for Our Projects
3. Data Risk and Cloud Computing

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

While that sounds good, the problem is that Sales often thinks the process they went through to gather very high-level requirements, draft a very high-level schedule, and put together a customer quote – i.e. final price – is all the planning that is needed.  In reality, the planning has just begun….

Behind before you start

When a project is handed to you in this fashion, you are immediately behind before you even start.  The tasks involved with planning for the project, preparing for kickoff, exploring the statement of work (SOW) in detail, and gathering your team takes time.  However, Sales has failed to put adequate – if any – time into the estimate and original draft schedule for these crucial activities.  Skip them and you’ll end up with inadequate upfront planning which will likely lead to significant project problems and scope creep later in the engagement.  Perform them and you’ll be over time and over budget right from the start and your customer will start to see that … and they’ll start to be very concerned … right from the start.  Behind the eight ball immediately.  Ouch!

Preparing to reset expectations

While change orders are scary things to bring up with the customer – especially on Day One of the project, you must, as the project manager, begin to reset expectations as quickly as possible.

However, before you do this, first re-draft the schedule using tools like Seavus’ Project Planner and Project Viewer and discuss in detail both with whatever parts of your team you’ve already assembled and your PMO Director or other leadership.  You should also meet with Sales and discuss with the account manager who closed the deal.  The reason for this is two-fold.  First you want to help ensure this never happens again.  Second, you want to gain any potential insight into the quirks of this particular customer so you go into a customer discussion with an idea of how they’re going to react to the news of the need to add in some planning time … and cost.

Tell the customer

Once you’ve re-drafted the schedule with planning time added in its time to set up a meeting with the customer.  Don’t over-do the estimate – it’s not in your best interest to be overly pessimistic or perform any padding as you’re likely to upset the customer anyway.  But you need to go into the meeting with ballpark numbers in terms of additional costs and stretched timeframe for the project.  And you’re likely going to have to mention the ‘c’ word.  Change order.  If they don’t ask for your head on a platter then you’ve possibly earned their respect by identifying this need as early as possible and bringing it straight to them for acceptance.  Some customers are like that … some aren’t.  But it has to be done.

Related posts:

1. Dealing with Unreasonable Customer Expectations
2. When Planning isn’t Enough
3. Project Readiness: Ten Things You Must Do Before You Start

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

Ideally, a project audit should be conducted by an independent examiner, who can remain objective in the assessment of information. In my case, the project audit was performed by our own quality control department, but all results were presented and scrutinized by our government customer and they also – in most cases – participated in the audit process.

The audit must be conducted in a spirit of learning, rather than in a climate of blame and punishment. If people are afraid that they will be “strung up” for problems, then they will hide those problems if at all possible. Such a benign atmosphere, however, is hard to achieve. In many organizations the climate has been punitive for so long that people are reluctant to reveal any less-than-perfect aspects of project performance. When organizations continue ineffective practices because they intend to help individuals avoid embarrassment or are themselves trying to avoid looking bad to the customer what they really end up doing is preventing any organizational learning.  It is said that audits conducted like witch hunts will produce witches.

Simply put, an auditor with a blame-and-punishment mentality is certain to create more problems than solutions.

The Audit Report

Audits come in different styles—comprehensive, partial, and informal and cursory. A formal, comprehensive audit should be followed by a report that, at a minimum, contains:

• Current project status. This is best shown by performing an earned value analysis.  However, when earned value analysis is not used, status should still be reported as accurately as possible.

• Future status. This is a forecast of what is expected to happen in the project. Are significant deviations expected in schedule, cost, performance, or scope? If so, the nature of such changes should be specified.

• Status of critical tasks. The status of critical tasks, particularly those on the critical path, should be reported. Tasks that have high levels of technical risk should be given special attention, as should those being performed by outside vendors or subcontractors, over which the project manager may have limited control.

• Risk assessment. Have any risks been identified that highlight potential for monetary loss, project failure, or other liabilities?

• Information relevant to other projects. What has been learned from this audit that can or should be applied to other projects, whether in progress or about to start?

• Limitations of the audit. What factors might limit the validity of the audit? Are any assumptions suspect? Are any data missing or suspected of contamination? Was anyone uncooperative in providing information for the audit?

This article was based – in part – on information from James Lewis’ book “Fundamentals of Project Management.”

Related posts:

1. What is a Knowledge Audit?
2. Knowledge Audits – Determining your Format
3. The IT Auditor’s Role in Project Management Process

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

Types of Costs

Estimating and budgeting project costs is not as easy as you may think. One reason for that is because there are so many types of costs that you should include in your estimate. Also, there’s the overriding issue of direct vs. indirect costs. There is a definte distinction so I’ll clarify these further.

A direct cost is an expenditure specifically and directly incurred by the execution of your project. These are typically the most obvious categories of costs, and include the following:

• Labor: The cost of the people carrying out the activities on your project. This could include contract labor. This is often the largest component of the project budget.
• Materials: The cost of items purchased for use in executing the project.
• Supplies and Equipment: The cost of items consumed by the project and specifically required to execute the project. This item could include items that are purchased, leased, or rented.
• Facilities: This would be included only if the facilities are built or purchased solely for the use of the project (in other words, when it’s part of what the project delivers).
• Training: Training specifically required to achieve project success. This cost is often associated with customer training during installation or startup.
• Travel and Other Miscellaneous Costs: Again, the only rule is that the cost must be required to execute the project.

An indirect cost is a cost related to supporting the facilities, general services, and organizational environment within which the project team functions. It may include the following:

• Fringe Benefits: This is the non-payroll component of workers’ salaries for the project. They’re often calculated as a simple percentage of direct labor costs and include Social Security costs, health insurance contributions by the organization, and profit-sharing plans, to name a few.
• Facilities: The cost incurred to maintain the environment within which the project team functions during the project. This might include building rent, utility costs, building maintenance, communications networks, office supplies, etc.
• General and Administrative: The costs of management and support services, such as secretarial, and the purchasing, accounting, and human resources departments, as examples.

In the case of organizations or companies that earn their money through project work, profit would be another necessary component of the project estimate, although not necessarily expected to be spent.

Information for this article was derived, in part, from Gary Heerken’s book entitled, “Project Management.”

Related posts:

1. Estimating the Project
2. Getting the Project Planning in Motion
3. Phases of a Construction Project Life Cycle – Part 3

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