Category: Project Management

Stoic Business – The Pre-Mortem

This post is part of a series (maybe) on applying the lessons of Stoicism in the corporate world. This post focuses on the Stoic practice of Premeditatio Malorum or “the pre-meditation of evils”, whereby you think or visualize all bad things that can happen to you, perhaps something you are particularly afraid of. Then you imagine how you would deal with and recover from it. The idea being that this exercise acts as a sort of inoculation for if the dreaded thing does happen and helps strengthen you against the trials of life, and perhaps help you realize that it isn’t all that bad either.

This practice can be applied to any business initiative, product launch, or project using a technique called the pre-mortem. This is an exercise I have use myself on several projects and at the very least is a good way to generate your initial set of risks to track and manage. However, it is also a way to get a temperature check on your team in a way that creates space for them to think about failure without being negative or being worried about being perceived as a Chicken Little. Unlike their managers, project teams often know long beforehand that a project is in trouble, perhaps even at the beginning when their estimates have been slashed without changing scope (hmmm).

via GIPHY

Far too often in the corporate world we only present and evaluate a highly optimized and ambitious plan without accounting for the inherent risks. This is in direct contradiction to Project and Program Management best practices, but unless we as leaders create the psychological safety for the team to engage in which is basically negative thinking, it is highly unlikely someone is going to speak up about risks they see as the hype train for the project gathers steam.

Typically, a pre-mortem is run in the following fashion, I would keep this to 50-60 minutes in duration:

  • Gather the team members together. Intentionally exclude senior executives and others who will stifle discussion at the team level.
  • Level set with the team that you are about to facilitate an exercise meant to identify key risks to the project/program/product, and you’re looking for them to start with a brainstorming activity in which you need everyone’s participation.
  • Announce to the team that the project/program/product has just failed and they have been brought together to identify the reasons why. [30 mins]
    • You must facilitate this discussion – don’t let people interrupt, talk over each other, debate the merits of the idea, etc. The goal of this portion is just to capture the things the team is already worried about but unwilling to bring up.
    • Do not end this earlier than planned, especially the first time you run this exercise. Let the team sit in silence or call on people. I also have 2-3 risks ready as part of my prep to help prime the conversation if needed.
  • Next, ask the team if any of the items are the same, or so related as to be combined. [5 mins]
  • Next, ask the team to assess how likely the risk is to come to actually occur. You could use a simple High/Medium/Low scale or whatever risk probability rating your organization currently uses (ask one of your Project Managers.) [5-10 mins]
    • Depending on the culture of your team you can either debate this openly, use a form of Planning Poker, or have everyone vote with colored stickies.
  • Lastly, look at the high likelihood risks, and ask the team two questions: [10-15 mins]
    • Are there any leading indicators that will warn us that this risk is about to occur?
    • Are there any pro-active mitigations we should consider to actively prevent this risk from occurring? (An example might be a risk to product quality that our entire QA team is inexperienced, when our estimate included 2 leads to run QA. A mitigation might be to overstaff that team, or to staff a junior project manager, etc.)
  • That’s plenty for one session thank the team and let them know you will take some additional time to assess the other risks and discuss with management or the client.

Now the question comes as to what do we do with this information.

  • First, spend additional time with this list. Put it into a risk register, clean up the way you wrote the risks and mitigations, and identify the impact of the risk occurring (for this you may need to consult specific team members and the project manager if this isn’t you.) After these additional deliberations and discussions you may want to adjust some of the risks, just be sure to communicate to the team along with your rationale or you’ll demand the trust the team has in you.
  • Present the risks to your management/client and, at least for the high likelihood risks, ask “are you willing to accept the risk of the documented impact, or should we include the proposed mitigation in our estimate” – do not waffle on this. They might proposed a different mitigation, and be open to that being a better option, but don’t frame the discussion in a way where they can refuse the mitigation AND avoid there being clear documentation what the dollar and time impact would be if the risk occurs. (Far too often I have seen clients and management act surprised and demand how we didn’t know about a risk when it was in the project documentation or even the contract from the beginning. This is just a tactic to get the team to eat it, don’t be a sucker.)
  • Regardless of the outcome of the discussions, document the meeting, the items discussed and the decisions made. Again, use the language “decisions made”, not some inconclusive discussion about hypothetical risks, but decisions made by management or the client on how THEY want to manage the project / program / product risk.
  • Ideally the risk register is part of your public team documentation, and you can just publish it and let the team know they key points in your next meeting. If not, specifically review the outcome of the discussions with ma

From here you or your Project Manager should manage the risks in accordance with your organization’s risk management practices.

For a robust description of project risk management see this PMI article: Project risk management–another success-boosting tool in a PM’s toolkit

If you have used this technique or something similar in the past, what was your experience? What did you learn?

Photo by Christina @ wocintechchat.com on Unsplash

Sad Truths About Project Rescues

This tweet got me thinking about the many project turn arounds I have seen over the last 20 so years. We’ve all seen the scenario play out time and again. The business pushes for more scope, faster delivery, and lower budgets. The project teams (I’ve seen this with both creative and IT teams) feel tremendous pressure to acquiesce to these demands. Even if the project manager makes a valiant defense of a rationale budget, scope, and timeline eventually they get worn down or overridden by their management and the inevitable happens. Management is promised a project the team knows in their hearts to be unrealistic, and everyone begins slogging away, hoping for a miracle, hoping for some break. Maybe some key elements on the critical path will come in early. Maybe the clients/sponsors will sign off on key deliverables within the planned 2 reviews. Almost never happens. If this is an IT project the odds are even lower, due to the vicious cycle of late and over budget projects which convince business sponsors that they need to dictate tighter budget and timeline constraints, knowing they will be missed, which in fact causes more projects to fall behind if not fail.

Then you have a project in Trouble. A project that is Red. And often, at least in the organizations I’ve worked with, people are brought in to to turn things around. I have had several of these put on my plate over the years, and the formula for success is usually very straight forward: tell the truth around what it is going to take to get the project done, or how much scope needs to come out to hit the time/budget. Yes, there are plenty of other things to do like look at the team structure, review and question the scope, re-vitalize the team, rebuild business confidence, look for efficiencies, etc. But for some reason that must be deeply connected to the human condition, when you first come on to turn something around, people are able to listen to reason. Even when what I am saying and calling for is exactly what the previous manager said, it was only once the project was in real jeopardy that the team was listened to.

And that last bit is exactly what I have found to be the key to success in turn-arounds. Listen to the team. Actually sit down with them, as many one on one as possible, and get them to open up about the project, what’s working, what is not, where they see the risk. For more thoughts on taking on a project in flight, see my previous post on the topic.

As for avoiding the situation, I would love to hear what others have found to be successful. And I would love to hear more pithy quips like the one that got this post started.

5 Rules for Managing Project Scope

It is often said that Project Management is not complicated, it is the disciplined application of basic project block and tackling, using simple well defined processes and artifacts. Of course that doesn’t make it easy, and many organizations struggle with delivering projects, let alone actively developing their project management discipline.

With that in mind, I am going to pick up on the theme of a previous post and work on a series of “5 rules” posts regarding project management topics. Each of these topics could each have a book written about them, and in fact there are many, many books on each of these subjects. My goal is simply to contribute some practical knowledge based on lessons learned over the years I have been delivering projects for clients. These projects have mostly involved technology of some type, but these haven’t all been “IT” projects, in fact many have been user experience design projects as well, and are just as applicable for agency account and project management types as it is for IT PMs.

Today’s post regards scope management. Poor scope management has to be one of the biggest, if not the biggest, contributors to project failure and budget and timeline overruns. It is the source of endless stress for PMs, and frustration for business sponsors/product owners. There are many factors that drive “scope creep“, and we can have a long discussion about the deep-seated mistrust within organizations that leads to unrealistic scope for schedule and budget – whether IT is padding their estimates, or whether business owners are unrealistic in their expectations, or dictate timelines without any basis of reality. However that discussion has no conclusion, and really depends on where you sit within the organization. My goal here is simple to give you as a PM, or possibly an Account type, some tools you can use in your daily project life to keep sanity.

As you think about the 5 points below, keep in mind they apply to four distinct elements of scope management:

  1. Product Scope – this is what the product needs to do, typically thought of as the feature set, or product roadmap. In agile terminology this is the collection of your epics, and to some degree the entirety of the User Stories in your backlog though it will never all be fully built. This is the long term vision of the project so it is never absent, just often poorly done.
  2. Release Scope – simply, this is the collection of Product Scope (features, user stories) selected for inclusion in your current project. Sometimes also called a Product Increment.
  3. Project Scope – this is work that needs to be accomplished to deliver the Release Scope to the performance characteristics defined by the product owner. Think of things like project management, team meetings, performance testing, etc. Really any activity the team needs to participate in that will affect your schedule. This is really only missed by inexperienced PMs, or people just pretending to be PMs.
  4. Scope Management Processes – this I find often gets missed, the very processes and meetings required to manage scope are in a way scope themselves, and each of the 5 rules below need to be applied to this category too.

1 – Write it down

This seems simple enough, but I am always amazed in reality how much scope gets undocumented, or is documented in so many places as to not have an official “source of record.” If you have a product backlog, associated business requirements, associated functional specifications, wire frames, visual design comps, meeting minutes, change requests, etc. you have yourself a potentially massive traceability problem. As a team, you have to define and agree on one master record, then you need to have processes defined for change management to ensure that changes to scope are clearly documented, approved, and updated throughout the documentation.

2 – Walk the team through it

For some reason, PMs seem to believe if it has been written down and checked into some document repository, their job is done. It is certainly not. It is critical that at least the lead for each track or discipline involved walk thru the scope together and raise (and document) clarifying questions. Your main goal here as the PM, it not to “defend” your scope document, it is to drive ambiguity and risk out of your project. I have found the team is usually good at identifying potential vague scope that needs drilling into, and they are definitely good at identifying scope that has the potential to take away their weekends. Typical times to do this are at the project initiation, during a mid-design checkpoint, and again when transitioning from design into development.

3 – Discuss it with your client or business partner

Do not fall into the trap of thinking that just because the project scope has been “approved” that you and your client/product owner actually have a shared understanding of what the scope document actually means. It is critical to have a review, similar to step 2 above, but this time you will also review the issues and clarifications needed from the team, and capture and resolve any follow-up. I also continue to be amazed at how often, simply asking “what else”, “what other…”, “anything else…”, elicits a response when everyone nodded their heads that we were closed. Your job as the PM is not just to facilitate the process, but understand the product – this enables you to have the insight to probe on grey and potentially missing areas of scope. Do so.

4 – Manage it

They way I think about this there are two aspects to “manage it” rule. The first one is generally dealt with in PM literature, often called Change Management, and that is to manage the intake of new scope requirements (and occasionally the removal of scope items.) The process for this is mostly an extension of the processes you used to capture the original scope, modified to be repeated over the life of the project. You need to be able to intake potential scope changes, validate, estimate the impact of them, meet with your clients to decide if they are in or out, and re-baseline you management metrics based on the new set of scope. Typically everyone understands this and the process are well documented in various books, PMO charters, manuals, ad nauseum. What I’ve found repeatedly missing is the PM actively monitoring discussions, meetings and design documents for the addition of scope that has not been agreed to. My experience is that both technology and creative teams too often over-eagerly agree to “just a little stretch” of scope here, and a little there, and pretty soon you have an unrealistic set of client expectations. I call this Listening for Scope, and it is a critical PM skill to develop an ear for scope. The best PMs do it naturally because they are detail oriented by nature, and so do some of the best Account people, (although they are less likely to stop it in front of the client, but that another post). However anyone can develop this skill, it just requires that you immerse yourself in the product/solution your team is developing as well as review the documented scope on a regular basis.

The second aspect of “Manage It” is managing what I call Scope Drift. This is the process by which the team and the client’s remembrance of what the documented and agreed upon scope actually means drifts apart, and if unmanaged can diverge significantly. If you have ever had a client say “Well, yes, I know we agreed on X, but I just thought that would also include Y” you may have unmanaged scope drift.

I have prepared a complicated diagram to illustrate this process:

As time passes, the shared understanding of scope drifts apart.
As time passes, the shared understanding of scope drifts apart.

So what to do about it? You can’t really ask the team and the clients to meet regularly and review scope – “hey folks, I know this deliverable is closed, but I want to get together and review it again anyways, just to be sure.” That would go over well. My approach to this is implicit, and relies heavily on that ear for scope I mentioned above. You can, and should, have design reviews, tech reviews, deliverable reviews, wireframe walk-throughs, demos, user testing, acceptance testing, etc. and during all of these meetings you must asking probing questions to drive out any assumptions being made about what is happening that isn’t shown, what is happening behind the scenes, and reinforce to the client (and the team) how what was reviewed maps back to scope. You can use simple statements like, “And as we closed on during the project definition, the Account Management functionality we just walked through represents the full set of account management features for this release.”

You might be surprised the difference that one sentence could make:
Scenario 1 : Sentence is not used. The clients and the team are both happy with the walk thru and all the designs are approved. The team believes they are done with Account Management, but in their head the client has approved the Account Management functionality that your team has completed so far. There are so many more exciting things the client wants to do with Account Management, and they can’t wait to see the next revision. This scope drift isn’t realized until weeks later, and the team ends up working several weekends to implement a compromise version of what the client wanted. The client is unhappy, the team is burnt, you go over budget and deliver late.
Scenario 2 : Sentence is used. The issue having been detected is taken offline and discussed later that day, you the PM review the agreed upon scope with the client and they realize that they had not talked to you about their evolving vision for account management. You agree to document the new items in the backlog for future releases. The client thanks you for being so diligent, the team is relieved and impressed they finally have a PM that knows their shit, and all is right in the world.

So there you have it – manage scope and everything will go as planned. Well, not really but still you do need to manage scope diligently

5 – Verify it

It should go without saying that after you have done all this diligent work to carefully document and manage scope that you also need to ensure that your team actually develops to that same scope. Every experienced PM has heard statements from their team like “well I knew the client wanted it and I had time” or “well I thought this approach was better than what we agreed to.” Exasperating to be sure, and truly the actual execution and quality of whatever craft is involved is the domain of you Creative Director, or Technology Lead/Architect, but you as a PM have to ensure that the proper quality controls and verifications are integrated into your plan, and that you involve whatever QA discipline you have available within your organization. But that simply is not enough. As we have already discovered and agreed upon above, no one in your organization knows the scope of this project better than you, so you have to be in attendance at these reviews and checkpoints. Maybe not all, but enough for the team to know that you are on top of it and you will catch it. It is also a best practice to have periodic internal walk-throughs, if nothing else you must have one before a walk-through is done with the client. Your other domain leads can help here, and be up front that the internal walk through is to make sure that everyone is on the same page internally and there is no misleading or unintentional scope or expectations set by the intended walk-through or the voice over for the session.

A Final Word

To make all this work, the number one thing that you need to instill in yourself and your team is discipline. Discipline to follow the scope management processes you’ve defined. Discipline to gently and professionally refer the client to you, the PM, when new scope or a scope disagreement surfaces. Discipline to hold the team and client accountable to the scope agreed to. Discipline to force yourself to have that difficult conversation early rather than let it go and hope the team will get ahead somewhere else so you can “sneak it in.”

Yes, being a PM can be difficult and thankless, but you picked this profession, now you have only decide if you are man or woman enough to do what needs to be done.

For a thorough discussion on the subject see the PMIs Project Management Body of Knowledge (PMBOK), search Amazon.com for project management, agile management, product management, or the many excellent blogs and sites on Project Management, a few listed to the right.

5 Rules for Joining a Project Underway

Note: this is content migrated from a blog I no longer maintain “The Grumpy PM” and was originally posted on March 21, 2009

Okay, there’s really nothing simple about joining a project as the PM when the project is already underway. You’re going to need to jump right in and keep the project on track while you ramp up on everything about the project.

However, while you could probably write a small book or a long article on this topic, I have found that five is the magic number as far as the limit of “action items” or feedback points you can give someone and hope that they would retain it. Three is probably better, but I am hoping my readers are brighter than that. [;)

1 – Invest in Relationship Building
Take the time right up front to meet with all your team leads and key stakeholders one on one. Have an agenda going in, but try to keep the meeting informal and ask open ended questions to get people talking: ask each how they feel the project is going, what is working well, and what could be improved. You want to get several things out of this meeting – you need to quickly build rapport and find areas of common interest you can leverage to begin to build relationships with those you haven’t worked with before; you want to see what areas are highlighted for improvement, so you can direct attention to them; perhaps most importantly, you want to try to sense how people are feeling about the previous PM no longer being there, which is probably why you would be joining after the project started. While the urge will be great to bury yourself in the project charter, scope statement, WBS, and project schedule, resist, RESIST!

2 – Get the Up to Speed, ASAP
In direct juxtaposition to the above, you will need to ramp up quickly on the project, but don’t do it at the expense of rule 1 above. Ideally, you can get access to the project repository/library/whatever and gain an understanding of what the project is about, but if you have to do it after hours or on the weekend, it is an investment well made. I usually go for the project charter, scope documents, schedule, and risk register. You need to demonstrate competence and confidence to all the stakeholders you interact with in that first week or two, when everyone will be judging the new PM, and the team will be deciding if they are going to rally around you. As you review, make a list of questions you want to ask of team members and stakeholders as you meet with them.

3 – Trust the People on the Team
It may be the hardest thing to do sometimes, but you are going to have to trust the people already on the project to do the right thing. They have history on the team, they (should) know what they are doing, and you aren’t going to succeed without them. More than this though, you need to show them that you trust them, by word and deed. In relationship to point 2 above, tell the team that you don’t know everything, they are the project experts and you am going to rely on them. When an issue comes up or decision needs to be made facilitate the decision making process, but get the people with the project tribal-knowledge, so to speak, involved. Another thing that seems to work with most people is to ask them to explain aspects of the project they are the expert on.

4 – Do Something to Shake Things Up
I am not a psychologist, so I can’t put this in proper technical terms, however I have found a significant, positive mental burst of energy and motivation can be had from the team by make some changes right away. It can be how meetings are run, how reports are presented, or even something like changing around how people are physically seated. Go for some low hanging fruit that you know will benefit delivery or the project. Certainly, you will be approaching the project with a fresh set of eyes, and you should try to bring enthusiasm with you to the assignment. Share your observations and ideas with the team in an engaging and motivated fashion.

5 – Resist the urge to blame the other guy (or gal)
I can’t remember a single project where I have jumped in after it was started where people on the team didn’t blame issues on the previous project manager. Don’t be that guy, it’s shows a clear lack of accountability for the project you now are responsible for, and it is unprofessional. Be proactive and identify all the deliverables, action items, issues, etc. assigned to your predecessor and put them on your to-do list. Stay classy PMs!

Passing the PMP

Note: this is content migrated from a blog I no longer maintain “The Grumpy PM” and was originally posted on March 6, 2009.

I sat today for the PMP and am very pleased that I can report that I have passed it. So, what can I recommend for anyone else who may be planning to take the PMP? Here are a few suggestions, but bear in mind that these are coming from the perspective of an experienced project manager. If you are just out of school, these points may not be as relevant.

  • Have a study plan and stick to it. If you are a PM, you really shouldn’t need to be told this, this should be second nature.
  • Start with a good study guide. I recommend going to a book store and looking at several to see which format works best for you. Then check your local library to see if they have a copy. Save a tree and save some money.
  • Purchase a copy of the PMBOK Guide, or join the PMI since you get an electronic copy free.
  • Speaking of which, you should join the PMI anyways, since the cost of membership pays for itself if you are taking the PMP (Membership is $129, and the discount off the exam is $150 as of this post)
  • Supplement your reading with other learning activities that engage other senses. I used the PMP PrepCast, which I highly recommend, to listen to while driving and hiking, and I also took some CBTs on the areas I was having trouble with (for me that was QA and QC, which we don’t typically deal with as rigorously in IT as in other industries.) The CBTs I took were available thru online training provided by my employer, check with your HR, you might have a similar benefit you aren’t aware of.
  • I also made lots of flash cards, one set focused on the ITTOs for each process, and another set of terms, definitions, formulas, etc.
  • Let’s see, what else? Oh, take as many sample questions and exams as you can. This is an area where I could have done more preparation, but I have never been much for practice exams. However, the PMI has some peculiar ways of asking questions, and taking a lots of pratice exams or questions is a very good way to get an idea as much for how questions will be asked aswhat will be asked.
  • Review. Especially review those topics you studied first – this was an area I had trouble with. I did the worst with the Initiating Process Group, which surprised me because it is one of the most straight forward (I thought), but it was also the first Process Group I started with and so it had actually been a while since I had reviewed it.

I guess that is pretty much it. And that is probably the last I will blog on taking the PMP exam. I am gearing up to join a big eCommerce project, and need to quickly switch gears from the PMI view of the world to the Agile methodology that is being employed on this project. Anyone have good tips or ideas on agile project management, please leave a comment.

PMP Preparation

Note: this is content migrated from a blog I no longer maintain “The Grumpy PM” and was originally posted on MONDAY, FEBRUARY 23, 2009

Well I am two weeks out from my PMP test date, and have been struck by a few things in particular as I go thru the PMBOK Guide in detail.

First, it is dry and boring. I guess that is why there are so many prep books and courses out there. I highly recommend either buying one, or for the cost conscious, check one out from your local library. That’s what I did, to include checking out the PMBOK guide. While I did get a free copy with my PMI membership, I just find I can’t study from a PDF document. However, since there is a new PMBOK Guide out I didn’t want to make the purchase of the soon to be obsolete version. The other resource I have discovered is the PMP PrepCast. I found this doing a simple search on iTunes, and what a deal it is for the money! For under $50 you get over 70 podcasts that you can take with you on your commute, on a run, to the gym, beach, back porch, where ever! I have been using this to reinforce the reading I have done on a chapter by chapter basis. The host also gives many test taking tips with each lesson. So, at this point I recommend a prep book of your liking and the PM PrepCast, we’ll see if I pass though.

Second, there is a lot of process and documentation (and hence a lot of work) involved in implementing the processes described. One of my criticisms of the PMBOK Guide is that it encourages the creation of process and documentation bloat over project execution. PMs could spend a significant amount of project budget just trying to implement all the processes. Now, technically, the PMBOK Guide accounts for this in the tailoring concept, whereby the PM is supposed decide which processes to use and which to keep. However, that idea is simply not stressed enough. In my experience, which is just that my experience doing IT project delivery, PMPs tend to overdue it and the project costs the client more in the end than need be, and the decision making cycle is much longer. Disagree?, let me know, as I am heading down the PMP path, I’d love to hear from others regarding their experiences with this.

Lastly, I continue to have a nagging feeling that the PMP is really just a scheme to rake in fees for PDUs. It seems to me that the cost for a lot of PDU-earning activities is high, and that the primary beneficiaries of the PMP is all the consulting and education providers who help PMPs earn and keep their certification. I’ll surely write more on this once I am in the re-certification stage.