Attributes of a Successful Project Manager – Part 2

In Part 2 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 have:

• General knowledge of project management
• Understanding of technology and some technical background
• Ability to work successfully as a problem resolution professional

These are just a few more of the key areas of expertise that the project manager needs to possess. Read on for further discussion.

Knowledge of Project Management

The first step for a newcomer to become qualified in project management is to complete a program of education. Meeting with others who are learning about project management is helpful, but it takes time. Alternatively, a prospective project manager can gather the information on his or her own. Those new to the profession don’t always need degree programs or pay large sums of money just to learn project management. Many of the world’s leading project managers learned their skills and techniques from experience and on-the-job training. That’s where the best secrets lie, and that’s why I thought sharing my experiences with project management would be helpful.

Technical Authority

Project managers often tell me that, as project managers, they do not need to understand the technology or technical issues because the technical resources working on the project will be responsible for the technical detail. Unfortunately, in the IT environment today, it is important for all project managers to be well-versed in the relevant project technology (including its applications and processes) and be able to communicate on technical issues with the “techies.” The majority of organizations that employ project managers insist that the project managers be able to take technical decisions and that they possess the necessary technical skill sets to be on a similar level as the technical staff.

I have heard many IT resources complain bitterly about project managers who haven’t got the foggiest notion of what needs to be done technically. The result is often that many of these resources simply carry on with their own development process and view the project manager only as an administrative manager who coordinates time sheets and ensures the delivery of status reports.

Project managers who are not well versed on the technical level find themselves (1) isolated, (2) lacking in credibility, (3) not consulted technically on major development issues, (4) not taken seriously, and (5) possibly even provided with false information. Project managers who understand the technology and can use it practically can apply such knowledge with outstanding results. Project managers also need to be certain that they have obtained the necessary project authority from the project sponsor and then communicate this to all stakeholders. This senior executive involvement often does the trick!

I always encourage project managers to make technical decisions if and when an opportunity arises, or to be involved in any way possible, by playing the role of facilitator or negotiator with the staff.

Sun Tsu said…

If the general’s employment of his mind is not in harmony with the army, even though the formation’s lightness and heaviness are correct, and the front and rear are appropriate, they will still not conquer the enemy.

Ability to Identify and Resolve Problems

Problems will arise on any project, no matter how much planning and effort have been made to avoid them. Recovering from any such problem means that the earlier the project manager can address the problems, the better. Identifying problems may require the project manager to review tasks with resources in order to find the real causes of these problems. If the causes are not within the manager’s own control or authority, then he or she must go to the project sponsor and seek advice there.

As alarming as this may seem, it may mean stopping the project until a solution is found, which is a good suggestion. Remember, the earlier you make the input to correct things, the smaller the input required.

Continuing to let tasks and milestones go off track will make it more difficult to correct the situation.

In Part 3, we’ll look at the project manager’s need for an ability to make timely and critical decisions, effectively select and manage a team of skilled resources, and to have a professional approach when dealing with management, teams, and the customer.

Book Review: Managing Project Uncertainty

Each month the people at Project Management Tipoffs (brought to you by Arras People) review a book in the Project Management realm and post the review to their site. I’ve worked with them to bring their reviews to our readers as well. “Managing Project Uncertainty” by David Cleden, was the subject for their June 2009 review post.

According to their reviewer, this book is simple and useful to project managers in the way it breaks down and presents helpful PM information. Please read on…

Managing Project Uncertainty (by David Cleden)

Few quotes from Managing Project Uncertainty resonate nearly as well with the project manager as Field Marshal Helmuth von Moltke’s ‘No plan survives contact with the enemy’ (pg. 28). Author Cleden surmises that von Moltke’s statement ’sits at the heart of any strategy for managing uncertainty.’ In essence, Cleden is talking about projects as if he is talking about the future – no one knows what’s going to happen.

The book is simple in other ways, like breaking things down about project uncertainty in relatable and easily-understood ways. Many readers will find figures like the Four Quadrants model a useful tool in identifying what you do and don’t know. There are also useful tables, including the flawless Hallmarks of Effective Decision-Making, and the book’s focus on the types of variables involved in managing uncertainty is detailed, thorough and open. Most importantly, Cleden is successful in implying that uncertainty arises on the project scene because today’s static world (when the project is planned) will not remain so (when the project is being carried out). You know the London 2012 Olympics needs certain facilities; what you don’t know are the uncontrollable variables (Political? Economic? Environmental?) that are going to wreak havoc on the effective delivery of those facilities. Those who planned to sell their property within the last year that have been left wishing they’d acted a year earlier are nodding their heads right now.

Cleden will leave you with a sound understanding about the traits, tendencies, timing and tenacity of uncertainty in projects. He is also adept at identifying certain methods that try to contain the uncertainty, and why some prove more successful than others. Those who expect risk management to be the be-all, end-all for uncertainty solutions will be in for a rude awakening. While you can’t always anticipate uncertainty, let alone the ultimate degree of difficulty it creates in your project, you can adapt, especially in a world of cost-effective budget management. Moreover, it might also be – in addition to being a good alternative title – the best glass half-full way of approaching uncertainty: “Managing Project Adaptability.

More information and review text about Mr. Cleden’s book, as well ordering information, is available at Gower Publishing.

Peer Review Everything

In school I hated to turn anything in misspelled or with handwriting that didn’t look how I wanted it to look. I took me a long time to ever start using pens because I always wanted to be able to erase and correct. Ok, I may have been a little OCD about that.

Even with my articles, I run them through spell checkers first – though that doesn’t catch a correctly spelled word that may be out of place or out of context. I try to re-read everything, but sometimes things slip through.

Proof and Test

The same care needs to go into our project deliverables. Proof, proof, proof. Test, test, test. When you hand a deliverable over to the customer – unless it’s understood that this is an early draft – then you’re telling the customer that this is done and the best I can do. It better be correct. It better be accurate and read well. And it better be free of simple typos, for crying out loud.

Bad Example

I had a project with a major US airline where I had two business analysts working on the project. One was more experienced than the other and was really acting in a mentoring role to the other one. The less experienced one was the BA actually doing most of the work. The understanding was – for my team AND for the customer – that the less experienced BA’s work was being overseen and proofed by the expert BA.

Ok…so when we had to go through 5 iterations of the Business Requirements Document (BRD) going to the customer with typos, inaccurate table of contents items, misspellings, missing graphics, etc. you can imagine how quickly the customer satisfaction we were building started to disappear! The customer couldn’t understand – and rightly so – how a team of 5 skilled technical resources (including me as the Project Manager) couldn’t turn in an accurate BRD without typos. Customer confidence dropped like a rock.

Never Assume

I was in the wrong for assuming that between two experienced Business Analysts that they could get a document handed over to the customer that was free of typos. I was busy, everyone was busy, and I expected it to just get done and be done right. It wasn’t until we started incorporating peer reviews for EVERY SINGLE DELIVERABLE that went to the customer that we started handing over error-free documents. We conducted peer reviews on the BRD (finally), the Functional Design Document, the Test Plan, and every piece of information that went to the customer in written (or electronic) form from that point on and we got it right. I even had the full team review the status reports, weekly status meeting notes, revised project schedule, and issues/risks lists before sending them off to the customer in order to ensure that the customer did not see any more incorrect and unprofessional submissions from our team.

Summary

Never take for granted that everyone cares as much as you do about the output that they deliver. Yes, it has their name on it, but if it’s your project it also has your name on it and everything comes back to you as the Project Manager. Work hard to ensure that emails are accurate and have the proper attachments the first time, that status reports are accurate, that status notes are accurate, that your project schedule has been updated with everything that the customer is expecting to see, and definitely make sure that the documents you deliver as part of your engagement are free of the simple errors and typos that make a professional team look very unprofessional.

This won’t necessarily increase customer satisfaction because it’s really just an overall expectation they should have anyway, but at least it won’t decrease customer satisfaction and that is definitely a good thing.

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

I’m assuming that most of you are like I am…you’ve been part of organizations that had good PMO’s, bad PMO’s and no PMO’s.  What set the good ones apart from others or at least seemed to make a difference?  Or if yours was bad – what made it so?  Why, in your mind, was your organization not served well by the presence of or creation of a Project Management Office?  And if you do not have a PMO, do you think your organization would be well served by one?  Why….what is lacking that you think a PMO would fill?

That’s a handful of questions and I’d like to hear feedback from anyone willing to offer information and answers – either anonymously or not.

Let’s assuming you’re in the category of individuals who think your organization is not being served well by your existing Project Management Office.  I’d like to hear your thoughts and reasons, but first I’m going to take a stab and what I believe are five reasons that the PMO sometimes does not meet the org’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

Let’s look at each of these in a little more depth…

Executive Management not Included in the PMO Process

This one means exactly what it says.  If your Project Management Office acts independently and either doesn’t report detailed project status up to executive management or if executive management doesn’t care what your PMO is doing, then your PMO isn’t relevant to your organization and it isn’t serving it effectively.  That may be the PMO’s fault and it may not be.  It’s sad if you have a PMO that your CEO does not find important enough to follow, view project status or have any interaction with.  Either your PMO Director is not promoting your PMO well, proper and meaningful reporting is not in place to make it relevant, or your CEO is clueless. 

Training Plans are Non-Existent

Most project managers could use additional or refresher training.  Technology changes, better processes evolve, and – in the case of IT shops – application development processes can change.  To stay current, to stay cutting edge – there needs to be training plans in place for the members of the PMO.  Otherwise, even if your PMO is important to your organization now, it may become irrelevant in the future as more and more PMO members become disgruntled with lack of growth opportunities and move on to other positions and companies.

Common Templates and Processes do not Exist

If your PMO is flying by the seat of it’s pants, then it’s not functional and it’s not likely to last.  It must have repeatedly process to be relevant and for the company to have confidence in it’s effectiveness.  Otherwise, no one will no for sure why one project was successful and another was not.  With no consistency your organization will not know what to tweak or fix in order to make things right or better next time.  Lessons learned will mean nothing if there is no consistent process and no consistent, meaningful templates in place.

Poor Upward Project Reporting

This one takes us back to the first point…the involvement of executive management.  Exec management may not care or get involved and that’s bad…but if there’s no meaningful mechanism by which to report project portfolio status (dashboards, etc.) to executive management, then it’s very difficult to show or prove PMO relevance to them.  You can show them how the PMO is making a difference if you can’t show them what that difference is.

Major Projects Circumvent the Process

This one may be the biggest tell tale sign that your PMO is not serving the organization well.  If smaller and less meaningful projects are being run through the PMO and managed by project managers…then that’s great.  But if they major projects go elsewhere within the organization and are managed by individuals that are not part of the PMO, then it’s obvious that executive management lacks the confidence in the PMO that is necessary to make it an integral part of the company’s success. 

These are just five signs…if I think of more I’ll post them.  If you have some to share please either post them here or email me at brad@bradegeland.com or both.

Keeping it Fresh: How to Keep Project Teams Focused on the End Goal

You know how things are when you begin a new relationship?  Remember how it was when you and your wife or husband first met?  Everything is exciting and new.  Ok, that’s not exactly how a new project is, but you get the picture.  When we start a new project, everything is fresh and new.  No budget issues, no project timeline issues, no issues whatsoever!  No one has complained…as far as you know requirements are in place and ready for work to start.

Is it Possible?

How do we keep that new car smell going longer?  It always seems to dissipate so quickly.  Everyone starts gung ho on the project.  No issues or roadblocks, no customer complaints, and the relationship with the customer is never strained at this point.  How can we keep everything cohesive and everyone fresh and focused intensely on project success?

The reality is we really can’t.  We’re all getting our project resources from a matrix organization and therefore everyone has not only your project priorities, but priorities of their own from other projects and from their management.  Customer issues will arise because requirements are never perfect and nearly every project has change orders (all should, but not all are caught or enforced….lots of ‘free’ work gets done or promised to the customer).

Keep Everyone Focused

As the Project Manager, it is our goal – and actually one of our key responsibilities – to keep the project team members focused on the prize.  That prize, of course, is the end goal of a successful on time and on budget solution for the customer.  How do we do that?  To really be successful, we need to keep our focus on the following:

• Aligning our tasks with the goals and mission of the project
• Assigning resources with relevant and meaningful tasks
• Keeping resources interested and challenged (this is often a tough one)
• Keeping everyone well informed with status information (weekly status reports, status meetings, adhoc communications, etc.)
• Keep track of the budget
• Keep the project schedule revised, accurate and in front of everyone

The well-informed team will retain more focus on your project and the tasks you’ve assigned to them.  Allow them no room for excuses – avoid the grey areas of who is responsible for what.  Keep the customer on their toes and aware of what is expected of them.  And keep them well informed of status so that they have no surprises.  Fewer customer surprises mean fewer customer complaints and less chance of having a dissatisfied customer.

Summary

You can’t keep it fresh throughout the project.  But knowing what causes things to stray like lack of focus, out of date information, unassigned tasks and lack of ownership and accountability will help you to steer clear of those issues by spending your efforts on performing the right PM tasks.  Strong and confident leadership will help you get to the end goal.