Tag Archives: Project manager

Bringing a Project Possessed into Conformity…

[Joining Critical Path and Risk Analysis]

On large projects, it’s often common to have 8 or more parallel, relatively independent work streams active at the same time. While this may seem like a lot to track, it’s really not … until several start to act as if they had minds of their own.

Living In The Moment…

The project plan had been carefully laid out with the assistance of the subject matter experts. The work efforts had been decomposed into appropriate work breakdown structures and the associated resources assigned / scheduled with their functional managers. Life isn’t good, it’s GREAT!

Then, one by one, risk probabilities increase toward realities. On one track, a key resource takes an emergency family leave. On two others, the IT teams, scheduled by external business units, declared that they would be “unable” to meet the timeline on previously-agreed-upon interface development. Three other interfaces show issues with their test environments.

Seemingly overnight, the complex, but achievable, project becomes a project possessed! Everything that could go wrong is! Risk analysis? Yes that had been done, complete with mitigation plans, but no one could have predicted such a concurrent set of events. Where to start?

Not Everything is Equal

Project managers often make the mistake of holding onto what THEY feel are the most important project constraints … Cost, Schedule or Scope … and don’t consider alternatives before it’s too late.

In a 2008 Harvard Business Review article, “The Experience Trap“, an international team of researchers highlighted how experienced project managers are often so tied to common delivery constraints (especially budget & time) that they ignore solution options before it is too late to employ them effectively.

though the managers had encountered similar situations on their jobs in the past, they still struggled with them in the simulations

The experienced managers still selected solution paths that maintained cost and timeline targets, in spite of the significant and probable risk to product quality or resulting in HR issues. The managers overlooked the option of working with stakeholders (and the project sponsor) to revise a project’s initial targets. A quality product delivery with a missed timeline target can still result in an effective delivery.

A project that delivers on-time and on-budget, but with poor quality can rarely be called “successful”. As project managers, do we often become too focused on our own achievements (on-time, on-scope and on-budget), missing solutions or options?

Analyze the Events

When “everything” seems to be going wrong at the same time, look at the situation and your options before acting. Re-examine risk impacts to determine if there are any unexpected impact increases triggered by concurrent events. Your initial risk analysis might have missed something or a mitigation option might no longer available to you.

Critical Path Analysis – Nobody Wants to be Late!

With the initial analysis in hand, start looking for where additional resources and/or modifications might have the greatest impact. A task or group of tasks with missed targeted dates don’t necessarily mean that there will be a day-for-day impact to the project’s completion date.

A project is rarely just a collection of tasks linked together to be executed in a single series order or “path”. A project is usually an aggregation of semi-independent work paths that come together at specific points to deliver a final product or result. The Critical Path is the longest duration path of tasks that leads through the project.

If a delay occurs to a task along the Critical Path (red line in the above example), it can have a significant, day-for-day on the project’s end date. A delay in a task (e.g. Task E or Task I) on a secondary or “feeder” path might be important, but not quite so concerning. That feeder path task, while scheduled to occur on a specific date, might have other dependencies/lags that allow its later delivery without an overall project timeline impact.

To understand where additional resources / modifications can be most effectively utilized, the project’s Critical Path must be identified.

The determination of a Critical Path for a project can be complex if done manually. If a project management tool, like Microsoft Project, is used and the project dependencies are properly configured, it will point to the path for you. While there can be exceptions to this approach, focusing attention on Critical Path tasks first is generally a “best” practice.

Review the Project Priorities

Your project may still be on track today, but the probability of it being there at conclusion might be remote. Where are your flexibilities?

Go back to the documents that initiated the project and look at the priorities. Everyone would like cost, scope and budget to be maintained, but which one or two constraints would the project sponsor and other stakeholders find less important than the others?

It’s not uncommon to find that the prioritization of primary constraints is missing from the project initiation docs. Risk events and mitigation plans are rarely popular topics when the project is “new and shiny”. If that’s the case, go back to the sponsor and stakeholders to capture their priorities. Expect some level of negotiation to occur, as now you’re talking about a likelihood, not just a remote probability of a missed completion target.

“New” marching orders in hand, you can now re-cast your project and bring it into compliance.

[Coming soon … Avoiding Delivery Issues: Critical Chain Project Management]

++++++++++++++

Related Articles:

When a Project Manager should Question the Authority

You want to do what??   Really?

Project managers are skilled in coordinating resources to deliver a specific product or process. Usually we’re provided the basics of a business case and often, a subject matter expert (SME) to fill in the technical details.

But what happens when the goals or the project approach don’t make sense to you?

Especially early in a project’s life cycle, project managers are often bulldozed by their SMEs and Sponsors into just focusing on getting the project on-the-road.

When will all that planning and organizing be done?                           When can we start coding?

Sound familiar? Unfortunately questions of this type are far too common. Project SMEs and stakeholders may understand the need for requirements gathering, but few have patience with a project manager who questions the framework of an initiating business case or a solution approach. After all, the project manager is not necessarily a subject matter expert and may not know much about the business operations.

That lack of business/technical knowledge, however, should be a reason to question authority! A project manager, uncomfortable with an approach or business justification, should challenge the team members to explain their positions.

While PMI processes don’t specifically call for a validation checkpoint when a project manager is assigned to a project, it is good practice to add one. Don’t wait until the cows have left the barn … ask the stupid questions of your team at the start!

It’s much easier to claim ignorance during the Initiation or Planning phases than it is during Execution. Those “clarifying questions” really don’t fall into the “stupid” category, unless they aren’t asked.

I was recently asked about managing an infrastructure conversion project. While I was familiar with the technology basics, I thought that a “refresh” was warranted. I wanted to see what solution approaches a project team might be considering. I probably shouldn’t have been surprised, but the “industry experts” posting on the subject, were offering the same basic structures that we had applied 15 years ago!

Document the environments, research the existing-state performance / stability issues, understand the business and application constraints. Perform these tasks as the foundation to planning. That wasn’t anything new!

Then it hit me. The SMEs reading that advice probably had less than 10 years of experience. They wouldn’t have been working 15 years ago, at least not in senior/planning roles. They probably knew the functions and the features of the technology products that they were about to implement, but they might not have the process perspective of an experienced project manager.

Challenge Authority

Less concerned about the technology specifics, I shifted my prep focus to the broader topics of the project approach. Let the subject matter experts do what they do best … provide specific information and expertise … but don’t assume that everything is OK. Ask questions about the business environments, the background work and the assumptions. When something sounds obscure or ill-defined, it often is. Ask questions and look for answers.

The answers that the project resources provide might highlight an area that was overlooked or a linkage that wasn’t considered. Conversely, the answers may provide no additional insight to them, but they will certainly add to your understanding of the project.

Properly done, such review sessions may allow your new team to show the depth of their knowledge and what they have thought about. Challenging authority doesn’t have to be confrontational (and shouldn’t be). It should be an opportunity to walk through the project’s key components and allow your team to express their knowledge. Where additional information is required, the assigned resource can later return to the team, after completing their research, and be the “answer man” (or “answer woman”).

Not Everyone is an Expert

You might find that you weren’t the only team member who didn’t understand a particular term or topic. On past projects, I’ve added regular technology and business reviews for the team members to give them opportunities to learn about their own environments.

These reviews were hugely successful in bringing the various team members up-to-speed on the project’s business and technology components. While watching 20-minute presentations doesn’t turn anyone into an “expert”, the briefings do give the team members (and stakeholders) a common understanding of project terminology and a better perspective on the issues that each face.

Questioning “the authorities” and challenging them to explain what they are recommending and why, can be an important part of project initiation. But remember, how those questions are stated, can be equally important. Be respectful. Be honest. Be focused on the project.

the project manager who fails to seek out and include the right subject matter experts is likely to deliver an end solution that isn’t 100% dead-on.  The result will be a customer who is less than satisfied and a solution that may not deliver the expected or desired results. 

PM_Value = (Reduction_of_Project_Risk *100) + Increased_Project_Effectiveness + Increased_Project_Efficiencies

What makes a Project Manager, Professional?

The Professional Certification vs Experience Bias

Like many Project Managers, who had “earned their stripes” in the delivery of projects prior to the popularity of certifying organizations, I have often looked at the PMI certification “tags” after a signature with a certain level of skepticism. Was this really a Project Management “Professional” or just someone claiming expertise after paying a fee and taking a test? While it is true that there are many highly skilled and greatly experienced PMP‘s out there, there are also many PMP’s who present themselves as more than they really are.

The value and meaning of a PMP certification, or really any certification, has been well discussed in blog postings across the Internet and over many years. (See below for links to several of those discussions). The posting that hit the mark for me is one from 2006 by Timothy L Johnson, “Those Star Bellied Sneetches“. He sums up the issues,

[The Dr Seuss book] is about class warfare backfiring, but I see many of the same parallels showing up in the project management certification debate … especially in hiring and staffing decisions.

The presence of a PMP “star”, especially in today’s recruiting practices, is often misinterpreted as a guarantee of success and its absence, a sign of risk.

While such assignment may be misapplied, the concept of an organization that certifies the professional skills and experiences of a project manager does have merit. Companies and public agencies today have significant project needs and complex initiatives that would benefit from a skilled project manager … a project management professional.

So What Makes a Project Manger, a “Professional”?

Skills

“Skills” are the organizational structures that a PM brings to a project along with the ability to apply them expertly. Whether these structures are expressed in terms of PMI/PMBOK Processes or an ITIL Framework or some other form, these are the tools that a PM uses to build a project’s definition, plan, execution and control. Expertise in using these tools effectively is a basic requirement for a PM, who falls into the “Professional” category.

Perspective [aka experience]

Classroom studies and readings can provide an understanding of particular PMI or ITIL deliverables, but they don’t explain people or problems. Project management is not about managing “things”. Project Management is about leading and managing people / teams. When performed at a “Professional” level, Project Management utilizes experience (and the perspective can come with it) to help the project teams to be successful in their delivery.

Ethics

While all adults may be expected to conduct themselves ethically, recent years have shown that it not always the case. To avoid any confusion over what is “ethical conduct”, PMI created a formal Code of Ethics and Professional Development  that is enforced under penalty of certification loss:

  • Responsibility — Taking ownership of decisions including their consequences. This includes knowing and meeting all legal requirements, reporting unethical or illegal conduct to appropriate management, fulfilling commitments and protecting proprietary and confidential information.
  • Respect — Being respectful of yourself, listen to others and protect resources entrusted to us.
  • Fairness — Being fair and transparent in decisions including disclosing conflicts of interest to appropriate stakeholders.
  • Honesty — Being honest in communications and conduct.

ITIL similarly places importance on ethical conduct, but handles the topic of “ethics” through its Best Management Practice Partnership with APM Group‘s Ethics and Standards Board.

Ownership / Quality Delivery

Finally, with a “Professional” Project Manager, there is an inherent sense of ownership of a project. Just as a gardener carefully plants a seed and nurtures it as it grows to maturity, the “Professional” Project Manager guides a project through its life cycle.

The end product (the “fruit”) may belong to the business, but the project itself is “ours”. We take pride how well our “seedling” is supported by the project tools and framework that we utilize. We may add more structure along the way (or remove some) to ensure our projects grow fast and straight. The quality delivery of the project is our responsibility as Professional Project Managers.

The Role of Certifications & Organizations

As much as I dislike the inherent inference of expertise that certification monikers indicate today, the certifying organizations do provide effective tools, structures and frameworks upon which project management practitioners can effectively build.

Certifying organizations also have the potential to further their stature by addressing the experience gap. Instead of accepting form-based experience validations, these organizations should consider the creation of modern (project management) “trade” guilds, where apprentices can learn under the supervision of experienced PM “craftsmen” and masters. Instead of discarding certifications, stronger mentoring links with seasoned professionals or structured apprenticeships should be established as part of certification requirements.

[Yes … I am a PMI-certified PMP.]

+++++++++++++++++++++++++++++++++++++++++++++++++++++++

The De-valued Professional Project Manager” by Bruce McGraw, 2012, http://fearnoproject.com/2012/03/17/the-de-valued-professional-project-manager/

If you have devoted your career to being a professional PM, like I have, you are frustrated watching companies put individuals into project manager positions who do not have the experience nor the skills to do the job.

Those Star Bellied Sneetches” by Timothy L Johnson,  2006,  http://carpefactum.typepad.com/my_weblog/2006/05/those_starbelly.html

[Dr Seuss book] is about class warfare backfiring, but I see many of the same parallels showing up in the project management certification debate .. especially in hiring and staffing decisions.

Project Management – A Modern Profession” by Michelle Symons, 2012, http://www.pmhut.com/project-management-a-modern-profession

But recognition of professionalism is not just about training and qualifications – it is also about continuous professional development and the ability to demonstrate the skills necessary to competently manage complex projects.

License to manage? (On PMP and certification)” by Scott Berkun, 2006, http://www.scottberkun.com/blog/2006/license-to-manage-on-pmp-and-certification/

I just don’t believe that on their own these things signify much about the ability to perform, especially as a manager. To be fair, I doubt any exam or degree can do that, which explains my general opinion about certification programs.

Why I’m Not a PMP“, by Glenn Alleman, 2006,  http://herdingcats.typepad.com/my_weblog/2006/05/raven_young_pos.html

I guess in the end the PMP moniker doesn’t appeal to me that much. It seems to be a “gate keeping” type badge.

How to handle Project Risks that become Realities

Do you see yourself as a realist?

It’s impossible to foresee the future, so why waste time trying…

Or do you see yourself as a compulsive planner, constantly considering a range of possible events that could impact your project?

Apollo 13 or Titanic?

Some project “events” will causally walk up and bite you. No warning growl. No alerting bark. Just a nasty event with its teeth sunk deep into your project’s leg. These are what I call “Apollo 13 events”. Regardless of the planning and preparation, there they are … with an evil grin, standing in the way of your project team … just waiting to explode.

Luckily, most project “events” evolve slowly and, for the observant project manager, provide some time to react before they actually become a reality. Some might retroactively classify the Titanic disaster as an “Apollo 13 event”, but I challenge that. The Titanic’s “unsinkable” myth, created in marketing of the ship, initiated a false sense of security among the crew and passengers. The resulting risks grew in impact as they became linked together.

The Titanic-iceberg event may look similar to the Apollo 13 explosion at its trigger point, both were sudden, dramatic and unexpected events, but the Apollo 13 event had a much more positive outcome.

Why?

“Houston, We Have a Problem”

In “Apollo 13”, the movie, the project managers are seen sweeping their work tables clear of charts and tables, to “start over” when the significance of the on-board explosion was understood. Such a dramatic clearing-of-the-decks may have been a realistic reenactment of the scene, it glossed over the “foundation work” upon which the support teams built their success. I agree that risk analysis and planning are not much for The Big Screen and that “foundation work” is often downright boring. But it was the years of planning, training and preparation that went into the management structure supporting that Apollo mission that brought those astronauts home. While the management team did not expect the explosion, they were prepared to act and respond in an organized manner.

To be successful when project risks do become realities, a project team should proactively build a foundation for risk management including risk definition, analysis (of probabilities, impacts) and mitigation/response plans. Working without risk management could be viewed as working without a safety net. You might survive a small misstep, but a fall could prove fatal.

In my project management experience, maintaining the risk register (risk management documentation) is not a popular project task. We all know that it’s important, but few of us particularly like to perform it. It’s not flashy and few people (outside of QA) seem to care much about it, until something goes wrong.

Managing Risks instead of Reacting to Them

Instead of using the risk register as a “QA check off” item, I strongly recommend that teams take its maintenance and update seriously. As noted above, proactive risk management often reduces risk impact and negates the need to react radically.

A single action taken early enough in a risk triggering sequence can completely avoid an event occurrence. The challenge is to see the initiation of the triggering sequence, not the end of the sequence (aka the event trigger). The observation of that initial change can most easily occur if the risks are routinely monitored and updated. (Risk management may be boring, but it can be extremely effective.)

When Your Ship Does Hit an Iceberg …

This is where the preparation pays off! Depending on the event, pre-positioning contingency resources can turn an “impending disaster” into just a “significant event”. Obtaining additional staff resources or additional funding to handle an event takes time. Reacting slowly to an event generally intensifies its negative impact. Preparation and planning are not glamorous tasks, but completed properly, they can plug a hole before “the ship” begins to list.

Clear understanding of the relative importance of project targets and goals can also turn a “major event” into just a “missed target”. When confronted with a the prospect of a missed timeline target, experienced project managers will often drive their teams harder to deliver. In a 2008 Harvard Business Review article, “The Experience Trap“, an international team of researchers highlighted how experienced project managers are often so tied to common delivery constraints (especially budget & time) that they ignore solution options before it is too late to employ them effectively.

though the managers had encountered similar situations on their jobs in the past, they still struggled with them in the simulations

The experienced managers still selected solution paths that maintained cost and timeline targets, in spite of the significant and probable risk to product quality or HR issues. The managers overlooked the option of working with stakeholders (and the project sponsor) to revise a project’s initial targets. A quality product delivery with a missed timeline target can still result in an effective delivery. It just means that the project manager cannot claim achievement of the Holy Trinity (on-time, on-scope, on-budget). A project that delivers on-time and on-budget, but with poor quality can rarely be called “successful”.

While we may not be able to predict the particular iceberg or explosion that might impact our projects, we can identify general risks and prepare accordingly. We can routinely monitor risks (scanning the horizon) to see if probabilities or potential impacts increase. We can prepare (pre-positioning resources / funds) for potentially high impact events and reduce the “surprise” of active triggers with monitoring (setting a bow watch while sailing across the North Atlantic).

As project managers, we don’t have control over everything, but with risk management processes, we do have significant control of our project’s destiny.

++++++++++++++

Related Articles:

  • The Experience Trap“,  Kishore Sengupta, Tarek K. Abdel-Hamid, and Luk N. Van Wassenhove, Harvard Business Review – February 2008

Why “Successful” Projects Fail …

[The Truth About Change Management]

The project satisfied its requirements. The project was delivered on schedule AND under budget. It was a “success”, right? … Perhaps.

The open question is: How was the project received by its stakeholders?

Some were very happy with it. Most liked it a lot, but there were a handful of stakeholders who were dissatisfied. They didn’t think that the project delivered everything it should have, but those stakeholders didn’t participate fully and had false expectations of what was within the project’s scope.”

Does that sound like the familiar lament of a “wronged” project manager?

It’s easy to blame those stakeholders for their own dissatisfaction, but is that fair or even correct?

The Project Management Institute (PMI) includes “Manage Stakeholder Expectations” as one of the five processes included in Project Communications Management. On smaller projects, managing stakeholder expectations would fall under the Project Manager’s responsibilities. On larger, more complex projects a Change Management specialist might be assigned to address that process/task group.

How Quickly They Forget …

Even though stakeholders may have participated in the requirements gathering / definition activities, they may not remember (or may have chosen not to remember) what was decided to be “in” scope or “out”. A good project management team will carefully document the project and deliverable requirements, as the requirements are used to determine product acceptance criteria and completion. As the project proceeds, additional definition might be added to the requirements (progressive elaboration), but the core requirements remain unchanged.

Both the PMI  and the Information Technology Infrastructure Library (ITIL) processes include Change Management methodologies to accommodate changes in project scope (when requirements are modified). These processes / methodologies allow the change to be documented, reviewed and approved, prior to development work or implementation proceeding.

Without strict Change Management controlling of project scope, many projects have problems meeting their schedule or cost commitments. These Change Control documents are also useful in helping stakeholders understand the project scope.

Change Management: Not Just Scope Control

While PMI & ITIL focus on Change Management primarily in terms of scope control, it is actually a much larger work effort. The PMI process, Managing Stakeholder Expectations, is mostly about Change Management, in spite of not being specifically identified as such in PMBOK. (PMBOK is  PMI’s Project Management Book of Knowledge. It is a book which presents a PMI’s definitions of project management terminology and guidelines.)

Even though the project documentation may, for example, specifically describe a data input screen in terms of its fields and functions, if, after Go Live, Stakeholder B  thinks that the font size on that screen was too small to be readable, then that stakeholder will be unhappy. He might describe the project as having “failed”. So whose issue is this?

Stakeholder B might have chosen not to fully participate in the interface review or acceptance, but that doesn’t change how he feels.

Regardless of the stakeholder’s abdication of his responsibility to review the interface, it is still the project team’s responsibility to manage that stakeholder’s expectations through meetings, demonstrations and, if necessary, one-on-one discussions.

Change Management is not just about controlling scope, it’s about communications, managing expectations, education/training and it’s about helping the user community and stakeholders adjust to the changes that the new process or product might bring to their organization.

When changes occur too quickly or too dramatically, stakeholders may have problems integrating the changes into their business processes. Regardless of whether a project met its goals (definition of “success”), it could still be considered a “failure” to the user community and stakeholders if they can’t effectively integrate it into their operational processes.

“Success” may be in the eyes of a project team or project sponsor. “Failure” is commonly in the world of the end users and stakeholders. At project closure, if the users aren’t satisfied with the end product, regardless of what a contract or requirements document might say, that “successful” project might still be viewed by them as a “failure”.

That’s not fair!

The project manager and team had worked hard to deliver on scope, on time and on budget. It’s not “fair” that someone is saying that the project is a “failure”? This is one case where perception really is reality. The PM can try to convince the stakeholder that he’s wrong, but it’s very difficult to argue with a “perception”. Pushing facts toward a stakeholder with a bad perception of project delivery is generally a losing battle. Perceptions are often based more on emotion, than fact.

The best approach is one that should have been taken much earlier in the project … communicate with the stakeholders. “Communicating” means more than distributing information at a meeting or via email. “Communicating” includes the delivery of information AND the confirmation that the information has been received and understood.

Managing Stakeholder Expectations is not just sending out emails. It’s engaging the stakeholders in active discussions of the project scope and the requirements. It’s about understanding their perceptions of what the end product or service might be. It’s confirming or correcting those perceptions long before Go Live.

If, after the scope definition discussions, there is still a significant gap between the documented requirements and what the stakeholder(s) understand is to be delivered, then the Change Control Process component of Change Management should be engaged. The Change Control Process moves the project team out of the line of fire and the perceived scope gap becomes an question of money and schedule.

Start Change Management processes early and continue them throughout the project. It’s always better to confront a problem head on than to allow it to grow and fester into a more significant problem that is difficult to effectively address later.

You Can’t Always Get What You Want…

While some say that Rolling Stones‘ “You Can’t Always Get What You Want” is a song about love, politics and drugs, I understand that it is the lyric ballad of a 1960s project manager. (Is it true that Mick Jagger is still PMI certified?)

+++++++++++++++++++

As a Project Manager, I am commonly provided a high-level project scope and expected to “flesh out” the requirements. While this is not an unreasonable request, as an IT Consultant, my role also includes a consultative / Socratic component surrounding scope definition.

You can’t always get what you want

In a time of tight budgets and low, internal resource, availability, not everything is practical, much less possible. Before heading down the road of requirements gathering, I make a point of performing a “sanity check” related to the business case behind a project initiation request.

That business case doesn’t have to be a formal, 10-page, single-spaced document, but it does need to exist in some tangible format. If the business case exists only as words spoken across a conference room table, then the first task of the PM should be to translate those words into writing. (“If you can’t print it, it isn’t true” or so my first IT manager used to say.) The business case includes functional description of the project and why its delivery is important to the business. It provides the basis for expending funds. In PMI terms, the business case becomes one of the source documents used to create the Project Charter.

Documenting the initiating business case, even if only a single page effort, solidifies the primary goals of a project and often, an initial description of they might be accomplished. It provides a project manager, who might later be “up to his elbows in alligators” a better understanding of “why we began to drain the swamp” in the first place.

But if you try sometimes you just might find

The business case documentation process may allow a review of solution options that had been previously overlooked. (This is where the “consulting” comes into play …) How many times have you looked at a problem and quickly convinced yourself of the answer, only to find out later that there had been a much better solution available to you had you just taken the time to consider the options.

Understanding (or documenting) a project’s business case may provide the PM and the requesting business unit with just such an opportunity. Instead of taking a build-it-now-and-ask-questions-later approach, ask those “Why?” and “Why not” questions before significant project funds have been spent. Even if you just hold a brainstorming session with your own team, the process may yield unexpected and positive results. Those results can then be shared with the project sponsor and the requesting business unit in a low-key manner. Remember, a project concept usually is somebody’s “child” and no one likes it when their child is called “ugly”, even in a well-intended manner.

You get what you need

The end result of this project process is that the sponsor gets what she or he needs. That might be the original scope / approach or it might an approach that delivers the same results but in a more effective manner. The important point is that the project initiation process now includes a business case that explains “Why”.

Both the project’s sponsor and the project manager “get what <they> need …

[… and, no, Sir Michael Philip “Mick” Jagger does not hold an active PMI-certification, I checked.]

+++++++++++++++++++++

The song, “You Can’t Always Get What You Want”, was originally performed by The Rolling Stones and released in their 1969 album Let It Bleed. It was written primarily by Mick Jagger with assistance from Keith Richards. [http://en.wikipedia.org/wiki/You_Can%27t_Always_Get_What_You_Want]