Monday, March 26, 2012

The Power of Process: How Bad Project Management Kills Great Ideas

We suppose it’s not only a lesson from Business 101 but from Life 101: Only move on to the next step when the previous step is complete. A maxim of Aurelian sophistication it ain’t, but how many inspired ideas have you had to relegate to the cutting room floor and how much time has your organization wasted because of a failure to adhere to it?
Here’s how it tends to happen:
  1. Core team in charge of solving problem defines parameters and begins work.
  2. Potential solutions to problem hypothecated.
  3. Broader decision-making team consulted for input.
  4. Refinements made, brilliant solution identified and recommendation presented to broader team.
  5. Member of broader team who missed first meeting provides new, contradictory input.
  6. Refinements made, somewhat less brilliant solution developed and approved by broader team.
  7. Core team begins operationalizing solution in order to meet aggressive timeline.
  8. Solution presented to senior executive: a mere formality according to broader team.
  9. Senior executive whose time was far too valuable to involve in the initial process is underwhelmed by solution – especially when compared to those posited by significant others, tennis partners and themselves; provides new data that changes problem’s parameters; turns out to be actual decision-maker.
  10. Organization engages in several rounds of all-hands meetings, early-morning conference calls, late-night emails and general all-around inefficiency to develop, get approval on and begin operationalizing new, decidedly mediocre solution.
In our experience (yes, even the mighty Brand Culture Company has made a few rookie mistakes), this dysfunctional workflow is usually not the result of pure ineptitude – it’s the product of best intentions. People and teams tasked with solving problems usually want to do so quickly and cost-effectively. When the schedules, availabilities and responsiveness of more senior stakeholders threaten to slow progress, they often proceed anyway – optimistic that everyone will recognize a great solution in the end.
But everyone doesn’t simply recognize great solutions for two reasons:
  1. Senior stakeholders may possess information that is critical to solving the problem, or that they believe to be critical. If that information isn’t addressed, the stakeholders are unlikely to be supportive.
  2. All people like to be heard. If they haven’t had a chance to weigh in on a process early, they’re rarely hesitant to do so at the end.
Here’s what we tell ourselves whenever a client asks us to help them solve a problem:
  1. Let’s find out who the real decision-makers are.
  2. Let’s make sure those decision-makers can participate in at least one initial briefing and one round of feedback on progress.
  3. Let’s not present any recommended solutions until we’ve had these briefing and feedback sessions with all key decision-makers.
While it looks so simple and obvious on the screen, it isn’t easy to adhere to when schedules are tight and the demands on peoples’ time are many. But when we’ve done so successfully we’ve found it not only increases our chances of producing great work – it helps us work more efficiently as well.

Article shared from PM Hut.

This article first appeared on BrandCulture Company’s blog
BrandCulture is a brand, marketing and corporate culture consultancy headquartered in Los Angeles. The firm combines the disciplines of brand building and organizational development and to create strategy, communications and culture programs that help businesses create preference in the marketplace and drive performance among employees.

The Ten Commandments of Project Management

Over the years I’ve seen many attempts to construct the “10 commandments of project management”. I believe there is an element of cheekiness in this as it suggests a divinely inspired set of rules, wholly encompassing (or should I say holy encompassing) a complete project management experience. Chutzpah or not, I am going to give it a go as well. But before I lay out my own proposal I’d like to provide a quick overview of those who so bravely came before me, putting their neck on the line in the search of the holy grail of project management.

So here we go:

Michelle Young Cavanaugh published the following in TechRepublic in 2000:
  1. Thou shalt have a project with goals
  2. Honor thy project objectives
  3. Thou shalt commit to the schedule that management hath given thee
  4. Remember thy checkpoints
  5. Thou shalt delegate tasks to thy manservant or maidservant or staff
  6. Thou shalt create a picture of thy project schedule
  7. Honor thy team members
  8. Thou shalt commit thyself and thy team to the project
  9. Thou shalt document extensively and keep thy team informed
  10. Thou shalt encourage creativity
James M. Kerr published the following in ComputerWorld in 2006:
  1. Thou Shalt Narrow Project Scope
  2. Thou Shalt Not Suffer a Fat Team
  3. Thou Shalt Require Full-Time Business Participation
  4. Thou Shalt Establish Project Review Panels
  5. Thou Shalt Not Provoke Burnout
  6. Thou Shalt Seek Outside Assistance as Needed
  7. Thou Shalt Empower Project Teams
  8. Thou Shalt Use Project Management Tools
  9. Thou Shalt Reward Success
  10. Thou Shalt Not Tolerate Quick-and-Dirty Work Efforts
 Robin Hornby, in “A brief guide to the art of righteous project management” suggests the following:
  1.  Thou Shalt Speak Thy Truth
  2.  Though Shalt Not Say ‘Yes’ in Haste
  3.  Thou Shalt Lead Thy Sponsor Down the Path of Reality
  4.  Thou Shalt Not Present a Single Point Estimate
  5.  Thou Shalt Pay for Quality, Just as Surely as Thou Payest for Thy Errors
  6.  Though Shalt Not Avoid Conflict
  7.  Thou Shalt Put Thy Stake in the Sand
  8.  Thou Shalt Not Plan The Unknowable
  9.  Thou Shalt Rid thyself of Incompetence
  10.  Thou Shalt Not Assume That Which is False
Edward Yourdon, citing the above ComputerWorld list, suggests the following in his Yourdon Report:
  1. Don’t fail to identify the key “players” who will ultimately declare “success” or “failure” for your project
  2. Don’t fail to clearly identify (preferably in writing!) what constitutes “success” for your project
  3. Don’t confuse “estimating” project schedules and budgets with “guessing” or “negotiating”
  4. Don’t ignore the non-linear nature of tradeoffs between people, time, money, and quality when negotiating key project parameters
  5. Don’t attempt to “freeze” user requirements; do expect “scope creep,” but don’t accept “requirements churn”
  6. Don’t allow developers and key end-users to stop communicating with each other
  7. Don’t commit teamicide
  8. Don’t ignore whatever software processes the project team has committed to
  9. Don’t skimp on risk management
  10. Don’t forget the importance of a “daily build” approach
 There are others, but I think I will stop here.
And now, without any further ado (drums in the background….), here’s my humble go at The Ten Commandments of Project Management:
  1. Know your goals
  2. Know your deliverables – Know what DONE looks like and Know how DONE is measured
  3. Know your schedule, cost and technical performance measures
  4. Know your risks and your risk plan
  5. Know your stakeholders
  6. Know your team members
  7. Adapt your communication to the listener
  8. Treat your team members with respect and with dignity
  9. Expect your team members to do their job but don’t demonstrate blind faith
  10. Take it easy – enjoy what you do – or else find another job
Article shared by  @ronrosenhead from quantmleap

Are You a Project Driver or Enabler?

Project managers are tasked with many simultaneous responsibilities. They manage and drive the delivery of a project while managing their team to deliver results according to the business expectations, on time and on budget. It's no small feat when this is accomplished seamlessly.

As a project manager, many times I find myself to be the driver, serving as the catalyst for movement and action.

A driver is someone who takes on the responsibility and accountability for the project deliverables. So, in addition to day-to-day team management, I drive the alignment of the team to the project plan, maintain quality standards with the delivered work and determine the project execution and communication methods.

Enablers act as complements to the driver. They go beyond the task of effectively driving the project activities and focus on the elements that empower the team by fostering a strong work ethic, high morale, satisfaction, and attaining personal and professional accomplishments. Enablers are very good at working with all the team members -- internal and external to the project and organization -- in such a way that allows everyone on the team to:

•    Align to the overall goal

•    Emotionally connect to why the project's overarching goal is important

•    See their own purpose on the team through their contribution and knowledge

•    Feel validated for their inputs and recognized for their efforts and outputs

Enablers add life and color to the project. They are known as the glue that keeps the team together. An enabler can exist within the project team, and he or she doesn't have to be the project manager.

The great value of project managers serving as enablers is that -- when combined with their authority, they are able to drive the project and enable their teams to deliver higher quality projects and longer lasting results. This value is reflected in the quality of the product or service, processes and process adoption rate, plus greater organizational awareness and integration.

Article by Dmitri Ivanenko, PMP for Voices of Project Management

Tuesday, March 20, 2012

Plan Project Requirements Framework

Project requirements are rarely collected and made available in a final form to a project team. Instead, requirements are often collected through an elicitation process, which involves a discovery, analysis, understanding and validation endeavor.

Usually, a business or requirements analyst carries out the requirements elicitation process. The project manager is typically responsible for planning and setting up the requirements elicitation and management framework.

Well-planned and well-managed project requirements are common characteristics of successful projects.

This simplified framework can be a guiding requirements checklist for project managers:

Organizational assets: Identify the available organizational process assets for planning and managing project requirements. The organization or project management office might already have standards, guidelines and templates that can or should be used as a starting point.

Stakeholders: Use the stakeholder register to identify the stakeholders who will help provide, collect, analyze and document the project requirements.

Categories: Identify and categorize the requirements types that are to be elicited, such as:

  • Project requirements: Business requirements, end-user requirements, functional and non-functional requirements, etc.
  • Product requirements: Technical requirements, product features, functional requirements, etc. 
  • Indirect requirements: Overhead imposed by organizational or enterprise environment and standards related to security, regulations, infrastructure and industry, etc.
Channels: Identify the channels through which requirements will come in, such as business-use cases, focus groups, requirements workshops, surveys, product introspection, reverse engineering or  imposed by the organization.

Documentation: Identify how requirements will be documented, whether it's textual form, graphically or using a formal requirements language. Identify the way requirements will be tracked -- through requirement tools, Word documents or spreadsheets.

Maturity Index: Establish the criteria by which requirements are validated and qualified. Is it clear? Does it make sense? Is the criteria aligned to the project vision and goals?

Prioritization: Identify the criteria on how requirements will be prioritized and scoped. For instance, list the must-haves first. Then come the "quick wins," requirements based on the owner prioritization, complexity and costs, the project phase, etc.

Risks: One of the main inputs for the project risk management plan are the scoped requirements. Identify the requirements posing a risk to the project. Develop risk mitigation, response and tracking plans.

Change management: Establish the criteria for detecting scope creep and basic rules for handling requirements changes for applying the change management process.

Article by: Marian Haus, PMP for Voices on Project Management

Wednesday, March 7, 2012

What The Hell Is Project Management, Anyway?

I thoroughly enjoyed this article written by Kevin Purdy for Fast Company. Hope you do to too!

"Project management" can sound like everything and nothing all at once. We spoke with a project management pro to clarify what it really means to get people moving in the same direction.

Project management seems like a classic chicken-and-egg career conundrum: How do you prove you’re adept at managing projects if you haven’t worked as a project manager? Beyond that, what does project management really entail, and how is it different from, you know, being a manager? And what tools do the pros actually use, since there seem to be a new one released every week?

To better understand some of the managerial speak around project management, I spoke with a 20-year veteran of the field, Frank Ryle. He’s worked as an international project manager for Arup International, managed construction and operation of the first Cadbury Schweppes factory in Russia, and now trains and teaches project management. Ryle analogizes project management to a nine-hole golf metaphor in his book, Keeping Score: Project Management for the Pros, available now as an ebook and due out soon in paperback.

In a phone interview, Ryle was, well, frank, honest, and eager to clear the clouds of vagary away from a field he’s worked in for most of his adult life.

Fast Company: Where did project managers come from? Have they always been around, just under a different name? Were they just good bosses?

Frank Ryle: Project management was just a thing you did, a job you had, but nobody wrote about it just a little while ago. You weren’t a ‘Project Manager’ in the 80’s and 90’s, but when something went good or bad, everybody else stepped backwards, and you were the one left. Project managers were the only ones who could talk about the process, not just the product. And, usually, you were the person who had the charm to do it.

Where do project managers traditionally turn to for education and improvement?

We all mostly learned by doing it. But after a while, it was the PMI (Project Management Institute), and particularly the PMBOK (Project Management Body of Knowledge). That’s a big book, and written for insiders. What’s that saying--once you put it down, you can never pick it up again? Since the first version, in the late 1990’s, it’s grown to about 37 official steps. It’s the de-facto bible.
My book is a simplification of that. One way of putting it is, if David Allen is about Getting Things Done, this book, and project management generally, are about getting bigger things done.

Let’s say you want to get project management experience, but you can’t really get that kind of leadership chance at work. What’s a good way to start expanding your skills on your own, maybe in spare time?

Everybody has projects now. Lots of people have projects in their work, they just don’t know it. Software has automated a lot of things, but not goals, resources, and products. That’s something you can find in all kinds of work.

What kind of person makes a good project manager?
You should be comfortable with ambiguity. You have to be willing to reshape the rule, the process, whenever things change. It’s really important to be comfortable with people too, different cultures, so much of business being international now. You’ll be called to walk into a situation where you don’t know the people you’re working with, maybe not even where, or their genders, and say, ‘How do I work with these people?’ You’ll have to create a bit of a roadmap for yourself, and, hopefully, be likeable enough to get by.

There are lots of tools out there, but it seems hard to know if one works until you’ve run through a project. How can someone make a good choice?

Use a tool if it suits you. And it’s a natural impulse, really. I’ve seen people set up big company-wide Microsoft Project installations, only to use it just to create simple Gantt charts. Don’t rush out and buy a Swiss Army Knife. If you hire a carpenter and they come to your home, you can ask them if they use a Swiss Army Knife, and they’d laugh at you. They’d have a good hammer, a good saw, a screwdriver. Some of our gadgets and software try to do too much. But some tools are great, and they’re getting better. We have, I’d say, another five years before we see the light with our software.

What do you mean by that?

There are people who get lost in projects, but we never know. People will ask them, ‘How’s this project going?’, and the response is, ‘I’m fine, but what have you heard?’ We need tools that are like a GPS in a car--they take information from three or four satellites, or, in this case, multiple clues. Software that’s aware of everything--the weather outside, price estimates, maybe even politics, in international situations.

So technology isn’t something that’s made project management necessarily easier, overall?

I think technology has given us a wonderful communications tool. But it’s made us more efficient, not more effective. There’s a difference: Remote working has put us in a position of having to impress our bosses, giving constant feedback, which is not what every project manager wants. The point of getting somebody to do something is to get it done, not to have them impress you.
When you wanted to get a team working on something back when, you’d get them together in a room, they’d pass bits of paper around, and they’d get it done. Once software actually gets us to that condition again, then we’re effective.

What’s one of the best tips you’d give someone managing their own projects, maybe in their off-work hours?

In project management, too many people don’t create a WBS, a work breakdown structure. They have a schedule, and they have a budget, and neither are accurate. You create a document that’s just the work, with names, the amount of work, estimates on the time for the work.
You’ll hear (as a project manager) people say that, if they had known all the work that would be involved in every step--deliveries, committees, approvals--their estimates would have been better. The WBS will make you better.

Follow on Twitter: @KevinPurdy, and @FastCompany