Dangerous ideas – and how to address them (part 1)

Ernest Baker, PMP, gave a presentation at the recent PMI Global Congress North America called ‘Ten troublesome project management ideas and how to combat them!’ I thought the content was worth sharing, as he had some good, practical examples of why things go wrong on projects and what we can do to stop them from happening.

Baker is President of Start to Finish PM, Inc and the aim of his presentation was to make us, as project managers, more aware of the “potentially bothersome” ideas that some stakeholders come up with. By recognising them, we would then be in a far better position to combat the dangerous ideas and assumptions about project management before they become a significant problem for the project. Essentially, it’s all about managing stakeholder expectations.

So, what were his top ten dangerous ideas? We’ll look at two today, and the remainder over the coming days.

1. Just Do It!

Baker said that the top symptoms of a ‘just do it’ culture were:

• Executing without planning
• Meeting a scheduled by doing not by planning
• Creating a fixed date schedule by drawing up the plan before the scope is defined
• Evidence of people mind-reading and not getting proper requirements or estimates
• Ignoring the balance between scope, schedule, budget and quality (a variety of the triple constraint so beloved of project managers)
• Lots of activity but not necessarily a lot of productive work taking place

In short, working in a ‘just do it’ environment means that you’ll deliver your project by luck and working a lot of hours rather than skilled project management. And it probably won’t deliver to stakeholder expectations anyway.

If you feel that you work with stakeholders who hold this kind of attitude, this is what you can do to combat it:

• Agree how things will be produced as well as what will be produced: this offsets some of the issues around taking the time to plan
• Include project management tasks and outputs as deliverables in the plan
• Gather metrics about time spent ‘doing’ project management – again, this will show that it isn’t that time-consuming a task and makes it transparent.
• Don’t charge your project management time (if you do time recording) to product deliverables. Instead, charge it to those project management deliverables in your plan.
• Incorporate lessons learned and process improvements
• Send your stakeholders on some training!

2.  Rewarding Heroic Behaviour

Sometimes, you need to make a concerted effort to get something done. Being a hero is sometimes a good thing, but Baker argued that it is often heroes (and heroines) that get rewarded – whereas the project manager that doesn’t get their project into a mess goes unnoticed. There is a risk with rewarding hero-like behaviour – the project managers stepping in to sort out a mess may find themselves in a high profile, high success role, but being in a mess is not a behaviour to reward at all. Companies which value heroes often overlook those project managers who plug away at it, develop excellent project schedules and don’t mess up. Surely that behaviour is more worthy? Symptoms of an organisational culture that rewards heroic behaviour are:

• Projects being completed by the heroic efforts of a team
• The leader of that team being praised for their work and leadership
• Resources are allocated from well-managed projects and given to the ‘hero’
• There’s a focus on managing issues instead of managing risks

Moving away from this culture isn’t always easy. In fact, as a project manager there is a limit on what you can do to influence organisational culture at the highest level. But you can address this challenge in some ways:

• Reward your team for the behaviour that you want them to show i.e. structured, planned effort
• Establish your project objectives and make sure everyone is clear what is expected of them
• Define success criteria at the outset, including what this will look like for stakeholders, scope and schedule.

Tomorrow I’ll be looking at three more of Baker’s troublesome ideas and how to address them!

IT Process Improvement – Staying on Track

In an IT shop, our PMOs and project managers rely heavily on the IT department for many things: support, personnel, technology for the project, and did I already mention support?

Process improvement and overall IT governance can make your IT organization transparent and in better alignment with corporate strategy, which better enables IT to support the various units within the organization – including the PMO.

This article is based loosely on information I gathered from an InformationWeek article from late 2008. Below are nine traps to avoid in order to keep your IT departments process improvement on track.

Poor Expectation Setting

Before leaping into process improvements, it’s critical to set realistic expectations for management, peers, and other stakeholders. A process improvement plan, like hardware and software buys, must have agreed-on requirements, configuration, and customization to be successful. It takes a long-term commitment, and unless your organization is willing to change, it will likely fail.

Lack of Balance

When looking at a process improvement plan, the people and technology landscapes must be considered, too. Think of people, technology, and processes as a triangle: Focusing too heavily on one area will pull the others out of alignment. When designing a software tool, consider the processes dependent on it and the staff who will use it. We’ve seen many organizations focus on one of these areas, not see results, and then move on to focus heavily on another area. This approach isn’t effective and often wastes money.

No Consensus

Some process initiatives are bottom-up, and others are top-down. In the end, however, process improvement affects many people, and without consensus, the initiative will fail. Resistance from one group or even an individual can impede progress.

Lack of Automation

The IT environment of today has never been more dynamic, and the ability to automate process between systems is critical. A few years ago, there was a lot of energy around startup runbook-automation tools that helped organizations automate processes. However, customers’ failure to buy these tools in large numbers took much of the steam out of this market. The concept is still a sound one: Automating complex IT processes helps reduce manual errors, meet compliance requirements, and track discrete tool costs.

Insufficient Commitment from Leadership

A bottom-up approach can jump-start the process, but without the support of leadership, the overall initiative will fail. Full-scale process improvement takes a significant, long-term commitment from the leadership team. Organizational change, investment in tools and training, and culture adjustments are all significant undertakings.

Lack of Practical Training

Hundreds of companies offer process training. Many organizations will specialize in ITIL or Six Sigma or PMI processes and PMP certification, and while these can provide a common vocabulary, most organizations stop there. We hear many stories, of companies that have spent good money to train their staff, but then are frustrated when the company doesn’t change after all that training.

Stagnation of Planning and Documentation

Like documentation, planning is important, but if there’s no way to incorporate it into the organization, planning isn’t much use. We see far too many dusty process documents sitting on office shelves. Typically, outside consultants or internal groups wrote them with the best of intentions, but they were never internalized or implemented.

No Workable Process

Processes can be extremely exciting for some, but you must guard against conforming to a single best-practice framework too rigidly. Some of the most successful process implementers start with a best-practice framework, and then blend elements from other frameworks and unique business drivers into their overall approach. While this may sound like heresy to some purists, best-practice frameworks evolve, and incorporate the best of what’s done in the field.

Hands-off Outsourcing

There are a lot of companies out there that would love to improve your processes. This option may sound very appealing, but make sure you do it the right way. You need to own the processes at the end of the day, and you know more about your business than anyone else, so take a mentoring approach rather than a total outsource. And be sure you allocate enough time to work with the outsourcer.

The Requirements Frustration Factor

I’ve written a lot about requirements and how critical they are to getting a project off the ground and headed in the right direction. In the long run on a project good requirements are important for the following reasons and more:

• Keeping the project aligned with original goals
• Keeping the project on time
• Keeping the project on budget
• Scope management
• Customer satisfaction
• Ease of development and minimizing re-work

When I’ve discussed requirements up to this point I’ve usually been referring to them in terms of larger engagements with formal, external customers. When you’re dealing with a cut and dried contract with an external customer, you have a SOW to work against, a set budget and change management is critical as is customer satisfaction, so therefore requirements and scope management are critical as well.

Internal Fiasco

So, what happens when you get an add-on internal project for an influential person within the organization and the requirements are somewhat grey? I had a project like this not very long ago. I was asked to run a project with the basic direction of ‘just do it’ along with my other projects and ‘make them happy.’ Fun!

When one of these falls in your lap, you can try to formalize things as much as possible and wrap good project management practices around it, but if the customer (in this case, internal customer) is not interested or willing to participate and at that point considers it frivolous attention to too much detail, what do you do? That’s the quandary…because I can tell you what happens if you don’t do enough.

I thought I was getting my hands around it… I met with the customer on requirements, documented them at the most detailed level I could since I was only working with the information I was able to drag out of them. They were basically ‘approved’ as I had documented and communicated them.

The bad news is that three months later at the completion of this small one-off process improvement project, one area was lacking the proper detail that this customer now wanted. (Notice I’m not going into too much detail here – it would not be in anyone’s best interest nor is it important for the point I’m trying to make.) Forget that fact that I had asked about this particular area of the requirements on two separate occasions and confirmed that we were like-minded…at least as far as I could tell with the minimal involvement the customer wanted to take at that time.

Of course, in the end the only real solution is to fix the issue and move on, which is what I did. But I’m looking back and trying to figure out how I could have avoided that train wreck with some different corrective action during the requirements definition period. Since it’s an important, visible, and powerful internal customer, playing the blame game really does no good…it’s still all about customer satisfaction no matter who’s right.

Lessons Learned

If this were to occur in the future, and I was still unable to gain the proper involvement from the actual customer, I would likely request that they appoint an individual to work directly with me in detail on documenting and finalizing the exact requirements. That is my lessons learned from this situation. That way, the internal customer truly has better representation in the process because they will assign a dedicated individual whose job will be to ensure accuracy on the customer side. Whereas, in the situation I was involved with I had that responsibility as well as the delivery responsibility and the end result needed re-work before it fully met what the customer wanted.

Unfortunately, I unwittingly walked into one of those “I’ll know it when I see it” type customer situations that we all want to avoid. I find that those are much easier to avoid when the customer is external and knows up front that they are paying extra for everything not documented as a requirement.

Project Manager of the Year Award

As reported in Trading Markets.

New York, NY, Jul 02, 2009 (PRWeb.com via COMTEX) — JW/A | Quote | Chart | News | PowerRating — International Institute for Learning, Inc. (IIL) has opened the application process for the 2009 Kerzner International Project Manager of the Year(TM) Award. A global leader in professional training in Project, Program, and Portfolio Management, Business Analysis, Microsoft(R) Office Project and Project Server, PRINCE2(R), and Lean Six Sigma, IIL established this prestigious international award in 2006 to recognize project management professionals who demonstrate superior performance, outstanding skills, and innovative project management techniques, as well as those who make significant contributions in business, industry, government, community, or not-for-profit environments. The Award bears the name of Dr. Harold Kerzner, Ph.D, M.S., and M.B.A., Senior Executive Director of IIL. Considered by many to be “the father of modern project management,” he is an expert in the areas of project, program, and portfolio management and is the author of a number of best-selling project management textbooks, including Project Management: A Systems Approach to Planning, Scheduling, and Controlling, which is now in its tenth edition. His most recent textbook, Value-Driven Project Management (John Wiley & Sons, Inc.) will be released in September of this year.

“Dr. Harold Kerzner is a true visionary in the field of project management and it is with great pride that we pay tribute to his contributions through the Kerzner International Project Manager of the Year(TM) Award,” said E. LaVerne Johnson, Founder, President, and CEO of IIL. “IIL is delighted to reward outstanding professionals for their dedication to the pursuit of project management excellence.”

Previous winners of the award have seen tremendous growth in their professional endeavors as a result of the honor. “Following my selection as International Project Manager of the Year, I have been very satisfied to see my career make a ‘quantum leap’, my network expand, and my credibility grow. The honor has elevated my status in the field, resulting in a new career opportunity that has profoundly changed my life and the lives of my family,” said Scot Hanley, PMP, MCP, 2008 Kerzner International Project Manager of the Year. “I have also been asked to contribute to Dr. Kerzner’s latest book and have been invited to lecture regularly on project management at the University of Alabama.”

To be eligible, candidates must possess the PMI(R) PMP(R) cred

Run Away! (And Other Helpful Advice For A Career in Project Management)

Run Away! by Cirofono via Flickr

I am passionate about project management in general, and helping people new to the field more specifically.

But let’s be honest. We’re all nuts.

Not Everyone Should Be a Project Manager

There is a specific form of gluttony for punishment that comes with the territory (some consider it a clinical condition). The decision to head down the project manager career path should not be taken lightly.

When I started out, there was a specific resonance I felt as I learned more about the role of a project manager. Everything I had really enjoyed about my previous positions seemed to be a part of this crazy thing called project management.

“You’ve got to ask yourself one question: ‘Do I feel lucky?’ Well, do ya punk?” – Dirty Harry (1971)

Hmmmm….actually I’m going to ask 2 questions instead. And maybe some sub-questions…what the heck. Being a contrarian is just part of my personality… though, it’s not a “desired skill” for project managers. Especially not when you are contradicting a quote you picked yourself like I just did. See what project manager employment does to you after awhile? Koo Koo…Koo Koo

Do You Fit In?

Those shiny, flashy careers in project management may seem inviting, but do you really have a passion for this kind of work? Does your personality lend itself to the type of work?

Do you like working with people? I don’t mean like social work, (although I might have something there) I mean being able to relay technical concepts to business people and get geeks excited about what upper management wants. You need to understand “Projects are about humans,” as the Project Shrink says. The importance of communication in project management has become a cliché, but nonetheless, it’s true. You need to do it effectively and fearlessly.

Are you passionate about this stuff? I really enjoy the process of creating something that never existed before. Even if it is not a tangible, physical product it is very rewarding for me to be able to think about what we did as a team. I love process improvement and change. That’s one reason why out of the various project management careers out there (project manager, business analyst, project controller, program manager, etc.) I chose to be a project manager.

Do You Like Challenge? (Glutton for Punishment Helps)

One of the great things about project management is that at least once a week someone starts running around the place wildly yelling “My hair is on fire! My hair is on fire! My hair is on fire!”

Seriously though, I can’t even smell burnt hair anymore.

Do you like thinking about a project from every possible angle? Because that is what you will need to do in order to be effective. The customer, the team, the sponsor, external stakeholders…they all have to be happy. You need to be able to change shoes every 10 minutes or so. The nature of projects is changing requirements and approaches as you go, so there will always be situations where you are the hostage negotiator that has to make everyone come out alive and feeling happy.

Do you thrive on change? The idea that a project plan is finalized and then very little changes from there is a fantasy… a theoretical construct that only lives in the pages of your project management textbook.

This doesn’t mean you throw your hands up in the air and let chaos rule… but it does mean that effective change management needs to be a key strength. Uncertainty and change happen, and it is all in how you deal with it (and anticipate it) that makes the difference.

What other questions should someone ask themselves before jumping into the alligator pit?

Who Is Josh Nankivel?

I am the founder of pmStudent.com, a site dedicated to helping new and aspiring project managers succeed.

Learn more about your project manager career path right now with my free eBook and newsletter!