The Triple Constraints of Choosing a PM Consulting Engagement

So I’m currently in the process of wrapping up a two-year consulting engagement.  And – as a professional project management consultant - my time now has to be divided equally between two very important tasks – closing out my existing project, and – maybe a little more importantly – finding a new one.

In going through this for the umpteenth time, I have begun to put a very familiar framework around what I see as the common components each of us examine as we choose amongst (hopefully) several opportunities for new PM engagements.  In other words  – how we evaluate which project to pursue and which to avoid.   I call this decision framework the Triple Constraints of PM Consulting.  Ring a bell?  And – like our Triple Constraints of Project Management (Scope, Time, Cost, and Quality) there are four…

My Triple Constraints of PM Consulting are: Content, Duration, Rate/Salary and Commute.  I compare these to the Project Management Constraints not only because they are the same in number (3/4), but because the relationship between the four is similar.   Whether Project or Consulting, the key elements always work in tandem with one another. In Project Management, where one of these elements is restricted or extended, the other elements will then also need to be either extended/increased in some way or restricted/reduced in some way. The same can be said for the Consulting Constraints. If one component is judged to be coming up short, the others need to supply enough positive value to effectively negate the downside of the first. When choosing your next consulting engagement, there needs to be a balancing  – based on your own personal and professional requirements  – of all of the elements in order ensure your (and ultimately the client’s) satisfaction.  Let’s look a little further into the Consulting Triple Constraints and examine their importance in choosing your next consulting “gig”.

Content – obviously, the actual subject matter of your next project is important.  Do you want to stay in a particular industry (like financial services)?  Want to focus on systems implementation? Or software development?  Want to do Buy Side? Sell Side?  All of the information you can gather about what the project is actually about and how much it interests you will play into your decision on whether it is right for you.  I also fold into the Content area the actual client for which you will be working.  Is it a firm that you’ve always wanted to work in?  Or – is it a company that you would prefer to avoid?  All of this data will get factored into your decision…

Duration – very simply, how long is the engagement (or project) supposed to last? Is it variable/open?  How much does that matter to you?  In many of the financial services clients that I have worked with, the initial length of an engagement usually ranges from 3-6 months.  Doesn’t matter  if the project supposed to move 3 buildings and 14,000 people from Massachusetts to Madagascar…the engagement is 3 months – with the infamous “option to be extended”.   How comfortable are you in accepting the project at the stated duration?  After speaking with the client, do you get the feeling that the project will go longer, and your engagement will be extended?

Rate/Salary – will this engagement be profitable for you?  As I’ve mentioned in previous posts, we should – as consultants – expect that our compensation will vary by project, year, even geographic location.  In evaluating a potential engagement, we have to decide if the compensation we are to receive – whether it be hourly or salary – is acceptable to us for the length of time the project has been slated for.  Notice I did not say “fair” – it may not be…You may again be asked to move that data center to Madagascar for $10/hr.  Or you may be asked to be the full-time Outlook meeting scheduler for $100/hr.  Is either “fair”?  What is acceptable to you as a consultant at that particular time in your personal and professional life?

Commute – It’s important.  Where will this new project be located?  Will you drive/train/boat there like an everyday commuter?  Or do you have to fly there Sunday afternoon and take the “red eye” back Friday night?  Is domestic or international travel acceptable (even desirable)?  Or do you want to be home every night by 6pm?

Once you have an idea about how each of these elements will be satisfied by your potential next engagements, you can go through the process of choosing and committing.  It may go something like this…

Project A is really something I want to do.  I’m very interested in doing more Agile project management, and Project A is all about Agile.  It’s also supposed to last 6 months, but the VP said that it’s almost certain to go a year plus. Tough commute, though…

Project B is pretty generic…data center move.  This one will definitely last a year – the contract will say that.  Its right on the commuter rail, and the hourly rate is about 10% more than my last project…

Which one would you choose?????????

Again – it depends on where your current priorities reside…if you are more focused on professional development, then you may go with Project A.  If, however, you strive more for convenience and financial gain, then Project B may be for you.  The important thing is that you realize that there are several distinct factors that must be weighed when evaluating your next assignment.  Decide what is important to you, and choose the project that best fits your needs.

SHAMELESS BOOK PLUG! – My new book has gone through its final (I hope) edit and is now being constructed into a final proof.  I hope it will be published within the next two weeks!!!  Update again next week!!!!

Industry Jargon 101: What is “Senior”

What would the financial services industry do without the word “Senior”?

There are Senior Vice Presidents, Senior Analysts, Senior Teams, Senior Management…and of, course, Senior Project Managers…

But what really does “Senior” mean?  I can tell you from personal experience that in one large organization, I was on three different “senior” project teams…for the same project…all composed of entirely different people…

So what is “Senior”?

Simply put, “Senior” here means “to be considered  more organizationally important.”

Does that mean that the position or team or person is actually better at their job or responsibilities than a more “junior” version? Does the “senior” have more experience? Better training?  Maybe they’re just older?

Not necessarily…

I think we’ve all come to realize that, especially in financial services, the word “senior” is placed in front of a title simply to give stakeholders an overall impression of advanced competence.  Or at least competence more advanced than a regular, or, g-d forbid, a junior person….

Creating this perception of greater competence, though, can be either a necessary evil, or a process that just makes all of us shake our heads in amazement…it depends on the situation…

A couple of examples…

I know of a small industry consulting firm – fewer than 10 people – that calls both of their PM’s “Senior Project Managers.”  They have no junior project managers, mind you, or regular project managers…or any other kind of project managers…so the obvious question is “Who are these Senior Project Managers senior” to?”

But look at this from their client’s viewpoint.  Wouldn’t it give you at least a little greater feeling of confidence to know that you were dealing with a person holding the title of “senior”?  That SOMEONE thought this person had enough knowledge and expertise to have earned that designation? I know its just a silly little word, but my experience has shown that both the vendor and the customer see value in this somewhat less than quantitative documentation of expertise.

A seemingly less productive use of the term “senior” is often found in large organizations that may use job titles as representations of internal organizational status.  Here, the word “senior” not only demonstrates your superior rank, but it also becomes a reward – in the form of a “promotion” – for a job well done.  Yesterday you were a Business Analyst.  Today you are a SENIOR Business Analyst. And sometimes the new title is all you get.  I have seen numerous situations where staff members are “promoted” to Senior This or That without receiving any more compensation.   And, in many instances, these employees are ok with the scenario because their new status in the company is worth as much to them as any raise in salary they would have received.  So again, just the addition of this single word could change not only how our stakeholders view our potential performance, but how we view it as well…

To all you “senior” professionals out there – take the title to heart.  Your customers expect you to live up to the designation – and you should, too.

PM Consulting in Financial Services – It’s a Living

I’ve been helping a good friend work his way through his first ever engagement as a full-time “honest-to-g*d” project management consultant.  This is a seasoned financial services professional who, when presented with this opportunity simply decided to give it a try. No formal training…no PMP…but enough industry “chops” to offer his client significant value in leading what is a fairly large scale technology program.

After several meetings where we went over various project management theories, deliverables, and approaches, he seemed to be catching on pretty quickly.  Really getting the hang of it…Another satisfied customer!!!!

So a week or so ago, we met over coffee to catch up.  Here – word for word – is exactly what he said…

“I kind of like this Project Management thing. Can someone really make a living at it?”

Hmmmm…Can someone make a living at it?

Well – the short and simple answer is “yes”…followed by a few “if’s”…

You can make a living (a pretty good one!) as a financial services project management consultant IF:

1.  You can accept that your yearly compensation will vary (sometimes greatly) – given the current – and probably future – economic climate, consulting bill rates most likely will not rise dramatically.  That said, there will always be an abundance of work in the middle tier range.  What a potential PM consultant needs to understand is that the rate (or salary) he/she is getting now may be greater than the rate he/she will get for their next gig.  Or it may be less.  And the difference may be in the range of 10%…15%….or more
2.  You are comfortable with preparing and interviewing for a new job very six months – consulting engagements are short term by nature.  Depending on your consulting position (contractor or FTE), there is a very good chance that you will be constantly looking for a new job.  If you are going to be successful at PM Consulting, you need to be prepared for this – and many folks aren’t.  The process can be both challenging and exciting, and always a true test of one’s networking prowess.  Still – once you get the hang of it, it is manageable.
3.  You are supremely confident in your professional persona and accepting of any/all duties assigned by your client – this is a big one.  We’ve all worked hard for our resume “letters” – PMP, MBA, SCM, etc.  – and are very proud of the multitude of multi-million dollar global initiatives we’ve delivered. What a PM consultant needs be ready to accept is that – depending on the situation – you may be engaged by a client who finds more value in your MS Outlook prowess than in your ability to calculate Earned Value.  THIS IS VERY IMPORTANT!!  You need to be ready to vigorously execute the most mundane project (or even non-project) activities with the same enthusiasm as when you’ve been asked to create fascinating and complex PM strategies.  I wouldn’t go as far as saying a PM Consultant needs to be able to swallow his/her pride…its more like you need to be willing and able to add  true project management value while having to execute the infamous “other duties as assigned”.

I was grateful for my friend’s honest question -I really hadn’t given the viability of my profession much real thought recently.  Now that I have, I remain convinced that its the right place for me…and that I can make a living at it.

PM Practices – The Project Management Abstract Question

Sorry I’ve been away from the blog a couple of weeks. Really had a good excuse, though – been working on the final stages of my first book.  Should be out mid-late May…and I will be publicizing the living heck out of it here, believe me…

…and had no intention today of writing, either, except for the fact that I think I have, in some macabre fashion, truly created  new genre of Project Management Practices – The Project Management Abstract Question.

I am calling it an area of practice because the Abstract Question is more than an ad hoc occurrence of mindless inquiry.  It truly is a consistent and often called-upon set of PM tools that I am almost 100% certain all of us have had opportunity to fully utilize.

So let’s define – a Project Management Abstract Question (PMAQ) is a stakeholder query that appears to thoughtfully and with good intent look to add significant value to a project but, upon further examination, is found to be… well… abstract...abstract because  – although impressive sounding at delivery – the question simply cannot be answered…at least in any realistic terns…

Couple of examples:

“How are we going to make up that time?”

“How can we be sure we captured everything?

Now we’ve all been asked those questions (and many more like them, I’m sure)…and I bet we’ve all asked this type of question ourselves…and either we tried to quantitatively propose solutions based on our years of training, or looked for answers from our colleagues as to how we might reverse the time continuum or guarantee their review of infinite knowledge.  Doesn’t work…

But still we are asked – and look to answer – the PMAQ…

What should we do?

I am by no means advocating we glare incredulously at our sponsors every time they inject a PMAQ…probably not a good idea…

The point I’m trying to make here (yes – there is one) is that we, as PM’s, need to focus our stakeholders on the realities of our projects.  What actually is achievable…what can be done…It is our job to identify and resolve the root cause of an issue, to propose and deliver concrete solutions. We must be able to identify when we are trying to solve the abstract, and direct our team’s focus back to tangible steps that will lead to a positive outcome.

Can we make up time? Probably not – but we can examine the schedule to potentially improve delivery by adding resources or working once sequential tasks in parallel.

Can we ever be sure we’ve captured everything? No, but we can create iterations of deliverables that allow our stakeholders the opportunity to review their products along the way and progressively elaborate to their final version.

Avoid the abstract – Look for real answers…

Project Management Fantasies #2 – What If There Was No Issues List?

I don’t know if you’ve ever noticed this, but it has often been my experience that a Project Issues List can take on certain magical qualities as the project progresses.  The “magical” Issues List seems to be able to make all Project Issues disappear.  At least disappear from the thoughts (and actions) of the team members.

It usually happens like this:

Day 1

Bill: Hey – I was testing the “Spruger” process and found that all of the “buy” transactions are showing up as “sell” transactions

Edna: Hmmm – that’s bad…better put that on the Issues List.

Day 5 – Issues Review Meeting

Project Manager Maria: I noticed a new issue with the “Spruger” process.  Who is working on that and what is the priority?

Edna: Oh , that’s high priority.  Better assign Tony  – he knows the “Spruger” like the back of his hand.  Too bad he’s out this week.  Let’s assign it to him and he’ll work on it when he gets back.

Day 105

Bill: Hey – I was testing the “Spruger” process and found that all of the “buy” transactions are showing up as “sell” transactions

Edna: Hmmm – that’s bad…better put that on the Issues List.

Bill: I think it’s on there.  Yep – Tony is the owner.

Edna: Great – we should be all set then…

Magic!!!!

Extreme case, I know, but how often do we forget the simple fact that Issues need to be resolved, not just documented…

So what if we had no Issues List?  What if every time someone identified an Issue, they had to stop what they were doing and resolve it.  No matter the priority, so matter how long it would take.  Would it make our projects run smoother?  Or – Would we possibly waste a lot time working on things that were truly not critical?

Without any real data to go on (after all, why confuse this with facts??), I will hypothesize that many projects would benefit from a “No Issues List” philosophy such as this.  Maybe not to the extreme, but certainly to the point where team members were empowered to forego a formal Issues review process and immediately try to resolve items that they decided were important.  Again, we get into words like “empower” and “decide” when we’re talking about team members – not standard vernacular when we look at many projects – especially in financial services where “command and control” are the words we more often hear.  Still, I think that allowing our team members this flexibility would have vastly more positive effects than negative – both in project delivery and team member development.

Now that would be some magic…

If There’s No “I” In Team, How do you spell Initiative? Part 2 of 2

So when last we met, we were looking at the lack of initiative on some project teams and trying to figure out why they performed (didn’t really) in this manner.   Toward this end, I posed the question:

Does one kill a team’s initiative by over-managing a project, or does the lack of a team’s initiative from the beginning cause one to over manage a project?

In practical terms, if we over-define and just assign our team their work with little input from them, do we then stifle their ability to create possibly better ways of doing things?

OR

Do project teams expect and require a very granular level of detail in their task assignments in order to remove the potential for doing the wrong thing and thus jeopardize the progress of the project?

The answer, as is often the case in project management (and consulting and probably even parenthood) is “it depends”.  It really depends on one key variable - the experience of the team.   The more experienced  – in both project work and subject matter – the more the PM can allow leeway in task definition, and the more he/she can expect the team to take the initiative to do more/better.   The trick is being able to judge the level of experience of your team and set-up the project management environment to both foster initiative while at the same time provide enough guidance to the team so that direction is firmly understood.

I equate this process to what one often sees on a network television newscast.  The on-scene reporter will cover about 90% of the story before going back to the anchorman/woman.  This allows the anchor the opportunity to “take the initiative” and ask additional questions.  If the anchor does not then ask about all of the pertinent information, the reporter will then fill-in what may have been left out.  That is what we as PM’s need to be ready to do – fill in the gap between the work that will be required by the project and the work that the team has planned (which will be a combination of originally planned  and newly ideated activities).

As for me – if given the appropriate opportunity, my own  preference is to NOT mandate every single activity for all team members and to allow not only input in task definition but even interpretation or – dare I say – deviation later on in the project.  Setting a project vision, defining solid objectives and deliverables, then allowing the team to work through the “how’s” has  – in my experience – consistently led to better end-products.  It creates room for initiative.  It almost demands it…

It can also be scary to some…There are the team members that must be mentored through this approach – with them we must reinforce the fact that mistakes will happen (are expected to…), and that’s ok.  It’s what we learn and how that manifests itself into a better deliverable for our stakeholders that matters.

So if you’re looking for some initiative in your project team, it can easily be found…next to the “I”…in TEAM.

If There’s No “I” In Team, How Do You Spell “Initiative?” Part 1 of 2

Ok, I know – again with the really trite and annoying title…still – what I want to write about this week is a thought that perhaps all of us as Project Managers have had when it seems that every day we have to push and shove and cajole and beg for any effort at all from our team – even on the most obvious and basic project tasks:

Can one kill a team’s initiative by over-managing a project, or does the lack of a team’s initiative from the beginning cause one to over- manage the project?

Heady stuff, I know…

I started to ponder this subject the other day as I was preparing for a “Lesson’s Learned” review on a recent project.  The project, overall, was what I would consider an “eh” in terms of success.  Fairly late from its original schedule estimate…over budget…scope crept in and out a little…but we did get the project done and folks were starting to reap the benefits.  All in all – a solid 6.5 or 7 on the 1-10 scale.

So in starting to write down what went well and what didn’t, my thoughts somehow turned to the concept of initiative  (I honestly don’t know why – I think I had just been reading about it in some business book).   I thought back on the last 12 months, and asked myself who on the project team had shown/taken true initiative – gone above and beyond without being asked, done something extra that moved the project forward, came to the front of the line and asked, “What else can I do?”

No one…Not one person, or act, or incident came to mind…

Was this really possible?  In over a year, had no one – really – shown any initiative?   Ok – there was one time when one person did some additional coding – took it totally upon himself without being asked – and created functionality that helped us along.  But that really was it.  For the most part, the project team waited (wanted???) to be told what to do and when to do it, then executed those specific tasks, and went on to the next.  And this became how we managed the project – this week you have these three things to do…then we’ll move on to the next three…

Is this a good model?  Should we plan our projects down to the level of assigning daily tasks so our team members don’t have to think about what to do? Ever?  Does that lead to the delivery of the BEST products? The most predictable products?  Does the acceptance of – or dare we say demand for – initiative during project execution lead to success? Should our team members expect that they will have to “take things into their own hands?” Or expect thing to be handed to them? Or – both?

Quite a few questions…in Part 2, I’ll discuss the answers…at least my answers…