The Trustworthy Project Manager

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 primarily on information from Scott Berkun’s book “The Art of Project Management.”

If you’re like me, you’ve probably had your fair share of managers. Many were forgettable, and some were downright awful. But for me, there were a few that I admired and they took time to earn my trust. They wanted me to do my best work, and they knew that this was possible only if I could rely on them on a daily basis. This didn’t mean they’d do whatever I asked or yield to my opinions by default. But it did mean that their behavior was predictable. More often than not they were up front with me about their commitments, motivations, and expectations. I knew where I stood, what my and their roles were, and how much support was available from them for what I needed to do. The bottom line – as long as I was staying on track, then I knew I could rely on them and they would back me up.

Do What You Say

As a leader or significant contributor to a team, everything depends on what assumptions people can make of you. When you say “I will get this done by tomorrow” or “I will talk to person ‘x’ and get that taken care of,” the other people in the room will make silent calculations, about the probability that what you say will turn out to be true based on what they know about you from experience. Over time, if you serve your team well, those odds should be very high. They will take you at your word and place their trust in you.

Although TV shows often portray leadership as a high-drama activity, real leadership is about very simple things. Admit when you’re wrong. Enlist the opinions and ideas of others in decisions that impact them. If you can do these things more often than not, you will earn the trust of the people you work with. When a time comes where you must ask them to do something unpleasant or that they don’t agree with, their trust in you will make your leadership possible.

Being a Good Leader

This implies that to be a good leader, you do not need to be the best programmer, planner, architect, communicator, designer, or anything else. All that is required is that you make trust an important thing to cultivate, and go out of your way to share it with the people around you. Therefore, to be a good leader, you must learn how to find, build, earn, and grant trust to others as well as learn how to cultivate trust in yourself.

The Importance of Project Management Software

Have you ever wondered how important software is for managing projects? How much time does it save? How much it can help you in delivering a successful project? What parts of it are lifesavers and what parts can you live without?

Having these questions ourselves, our company has conducted a research with a subject “Project management on an enterprise level”, during the past month, supported by Seavus Project Planner and Seavus DropMind™. The main purpose of the research was to identify the needs and requirements of people who are faced with project challenges everyday.

The research has shown some very interesting results that we would like your input on.

Part I

First, let’s share the statistics about the respondents. The first part of the survey was dedicated to analyzing industry the companies operate in, company’ size, location and job title of the respondent.

From the responses provided, most respondents work in companies within Manufacturing (13.40%) and Consulting (11.34%) industries, directly followed by Business / Professional Services (8.25%), Construction / Home Improvement (8.25%) and Government / Military (7.22%). Other industries presented have less than 7 % of respondents.

Regarding the companies size, most respondents work in SME (24.74%) directly followed by companies with 1000-10000 employees (18.56%). However most of these companies have between 1 and 3 offices (51.55%).

The job title of the respondents is summarized in the graphic below:

We believe this reach provides an accurate sample of the PM market, and that the conclusions can be trusted.

Part II

Next part of the survey was connected to the actual usage of the project management software that is chosen within the responders’ company.

We wanted to explore the usage of the Microsoft® EPM within these companies and more or less we were surprised by the answers. It is interesting to see that large number of companies that have been using MS Project Standard are not using Microsoft® EPM and do not even consider implementing this solution within their companies.

However, it was also interesting to see the importance of different parts constituting the project management solutions for the people using Microsoft® EPM (or for those that are considering using it in the future) and for the people who haven’t been using it or are not considering using it in the future. We have divided the most important features in 4 categories: Project Management, Resource Management, Time Management and Collaboration. Follow up the appropriate responses in the tables below:

(The green colored cells are related to respondents who are or will be using Microsoft® EPM and the orange colored cells are related to people who are not or will not be using Microsoft® EPM).

As you can notice all of the features above are important and very important for the biggest number of the respondents, except for the wikis which both groups has indicated as not important feature. Moreover, almost 79% of respondents stated that it is very important or critical for them to track project progress. Assigning privileges/roles is valued with 3, (on a scale from 1 as useless and 5 as critically important), from almost 50% of the respondents and for all respondents is important to know that their project is on budget and on schedule.

Other interesting answers were given on questions such as where the respondents store important documents (.mpp files; general documents and project related documents). The answers were diverse, since this was an open question. However, some of the most frequent answers were: on the Server, SharePoint, Network, and File Server and it is more than obvious that people want to have their pm solution installed on the server in the company (89%) than to have it hosted (10.81%). Moreover, they prefer to install the solution from their own IT department (75.68%) than to have the installation from the solution provider (24.32%), but almost 57% of the respondents are ready to pay for installation and support from third party.

The answers on the question “How the teams update task progress?” were expected. 37.55% of the respondents stated that e-mail is used for updating task progress. Surprising 18.18% of respondents verbally update tasks and 15.58% use MS® Excel. Software programs were mentioned by a small number of people.

Same answers were given on the question “How do you share info about late tasks, risks, or general project related knowledge?” with 75.32% for e-mail, 48.05% verbally and 28.57% MS® Excel.

This survey provided many valuable answers, but as you can notice, there are some conflict areas. We encourage you to share your opinion on the results and moreover your experience in the field. Let’s create together the big picture of this survey.

Book Review – The Lazy Project Manager

Just as over the past few months, at the request of the Arras People, I am bringing you their October book review.  This time, it’s “The Lazy Project Manager” by Peter Taylor, who now also write for PM Tips.  The book review was authored by John Zachar.  John’s views of the book that he expresses as part of this review do not necessarily reflect the views of his employer, APM.

Book Review – The Lazy Project Manager

Peter Taylor, available through Amazon

Review by John Zachar, APM

It is extremely unusual for me to pick up a ‘management book’ involuntarily. I think I lost that particular desire when I did my MBA in the nineties. However, occasionally there is a need to acquire additional information or background knowledge.

So it was with some trepidation that I picked up Peter Taylor’s book one Sunday afternoon, knowing that I’d promised a review. I finished it later that day, having only put it down for a meal. I really, really enjoyed it.

I’ve read a number of the ‘jokey’ type of management books over the years; those that have catchy titles, and purport to be a fun read, yet seem to be. This time I was pleasantly surprised that the book not only caught and kept my attention, but that it did it in a very enjoyable, easily absorbed way.

Peter’s use of analogies and stories is where I found some of the value. The remainder of the value came in the real content of the book. Over the years as a project / programme management consultant, lecturer, teacher and practitioner, I’ve built up a pretty good education about how to manage change into organisations through projects. I cannot find fault with any of Peter’s recommendations – especially the bit about being lazy!

Peter has been able to enrich the content by using his stories and analogies to make a number of points, all of them common sense; even things like “it is important to separate the important from the immediate” (my words not his – you find his analogy in the book).

One of the analogies that Peter uses, almost from the outset, is that of a dinosaur – in fact a brontosaurus. “I’m sure you know the one, thin at the front, thick in the middle, then thin at the other end.” Well, Peter modifies the analogy a bit by saying that projects should be thick at the front, thin in the middle and thick at the other end again.

The thickness of the project shape represents the amount of effort or work that needs to be done at that stage of the project. The corollary is: initiate well, compensating for difficulties, be lazy in the middle because a well organised project can run on its own like a well oiled machine if initiated well, then put some effort into finishing with real enthusiasm, helping all the stakeholders realise how well it has gone, and what a wonderful result we have.

Organising your project in this fashion allows you to apply the principles of being a lazy project manager – and still be successful. That is really what it is all about.

Don’t forget: this is not about just being lazy and not doing the job – this is being lazy, and being successful as well. Do the job, but do the job in the most intelligent way you can, so that you can be lazy when you can. That is my kind of project management. The other bits that are interspersed throughout the book are about how to achieve the above by using a great deal of common sense.

Peter’s book made this entertaining, yet useful for me.

This article originally appeared in the October edition of Project Management Tipoffs, the project management issues newsletter from Arras People. Subscribe to Tipoffs today.

ABOUT THE AUTHOR: John Zachar is the Product Development Manager with the APM. He has previously written for both Tipoffs and How to Manage a Camel, and would love to hear your feedback. Feel free to contact John with your thoughts about The Lazy Project Manager at john.zachar@btinternet.com. This review is the work of Mr Zachar and is no way connected to any views, beliefs or opinions of the APM.

Criteria for Successful Project Management Offices

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

More on Lessons Learned

It is my belief from my years of project management that performing a lessons learned activity is one of the most critical processes for future project success and yet also one of the most overlooked and underutilized. We tend to get to the end of a project and breathe a sigh of relief and move on. Rather, we should hold one or more formal sessions with our team and our customer to identify what worked and what didn’t.

The customer always has a lot to say about any implementation and their opinion and input matters greatly. It’s best for you to hear it in a formal lessons learned process rather than have your customer follow-up with your CEO and give him an earful.

I’ve published some of my thoughts on Lessons Learned previously including an article from February 2009 titled simply “Lessons Learned.” Here, I present some further thoughts on lessons during the project implementation process from Jason Charvat’s book “Project Management Nation.”

Lesson Learned During Project Implementation

“What could be simpler than buying some computers, throwing them on a desktop, plugging them in and turning them on?”

The question is simple: The answer is much more complex. Complexity is almost always underestimated until well after the start of the planning process. Many of the elements of deployment require special coordination and handling due to the lack of direct control over the processes or compounding dependencies. Complexity can come from the technical nature of a project that attempts to take advantage of a new technology not yet tested by the corporation and requires full integration into the existing systems. These factors don’t surface until the project manager demands action or some form of change. Implementing a solution without testing it properly is not acceptable.

I Wish I Had Known That

Look for early warning signs that planned business benefits will not be delivered.

• It is not clear that achieving the business benefits is the top priority of those managing the project.
• Time scales and resources for training, testing, and implementation support have been eroded by project slippage, and there are proposals to cut corners.
• Acceptance testing is being carried out by IS specialists and there is no involvement from the business.
• Other parties, who were not previously identified as part of the project, are now being identified as needing to be involved in acceptance testing and implementation.
• Staff involved in developing and agreeing to the original business objectives have moved on.
• The supplier has not demonstrated that the new system is compatible with existing systems and peripherals.
• The solution needs to be tested and demonstrated within the proposed environment (including links to existing systems). Have the tests for accepting the system from the supplier been planned and agreed upon? Has the process for data conversion been planned and has sufficient time been allowed for it?
• All necessary on-site preparations were not included in the planning (e.g., accommodation, cabling, safety, and security).
• All dependencies, such as slippage on other related projects, have not been taken into account.
• Too little attention is paid to testing the final solution.