We’ve all had it happen to us. We were able to get a signed agreement in hand, identifying agreed upon scope of work. Everything for a fleeting moment is right in the world. Then it happens. That one stakeholder (you know who they are) comes to your desk and asks. “Can we add this one little tiny feature?” or “Can we make this one tiny little change?”
Are you kidding me? This reminds me of when my son asks if he can have dessert when he hasn’t eaten his dinner. Though you can’t be as abrupt with a stakeholder like you can with a 4-year-old, the answer should still be the same. No.
Though you should not be an obstructionist, we could all learn a little from Dr. Cox in this case. His (command) mitigated speech is all he needed. In the real world, stride to be a win-win negotiator and be aware of the mitigated speech being used to conduct your negotiations.
I sat in a meeting Friday afternoon to meet the new guy over at the vendor’s office and give my assessment to my client. It never gets boring, listening to rhetoric from a vendor. They usually speak to my client, not with my client. A few months ago, after I asked the vendor a very specific question about the sloppiness of a metric, the vendor replied Do you have a problem with that!? Well, actually, I think both of us (the vendor and I) have a problem. We’re both here to ensure this client gets quality work. It doesn’t matter if it’s a software build, documentation, or even a graph is a slide deck. The vendor lamented and the metric actually makes sense now.
The new guy, though perhaps giving us lip service, actually established himself as a bridge builder and communicator. He said he wanted to know our concerns so we’ll all be in step. He gave us his email address and mobile telephone number, telling us not be hesitate contacting him. When we pressured him on a request we’ve been demanding from the previous leadership, he said they would figure out a way to get it done. When asked of our first steps going forward, his response was…
Let’s do what makes sense.
What a refreshing response. No “let me get back to you”. No “let me check with my boss”. It was a direct answer. It was ambiguous but I thought it was acceptable considering the situation. Compared to hearing traditional responses like “Ya, we can do that” when asked to if the vendor could make a change or deliver something, this guy actually said Let’s do it. If we can be in agreement as to what makes sense, we’re golden.
At the end of the day, I don’t care what they can do. I care what they will do. Let’s hope we’re turning over a new leaf.
I just reviewed an Integrated Master Schedule (IMS) comprised of almost 5000 lines. I didn’t write the thing. I was just asked to review it. You might be saying to yourself that must be an absolutely awesome schedule, detailing every nuance of a project. Counter to that, you might be saying to yourself that is the most overdeveloped schedule ever creating, complicating the most trivial of work.
In the business of project management or leadership, you should always be asking yourself, “does this make sense?” If it doesn’t, you should be looking for the Goldilocks approach to documentation or process. Do something that is not too complicated or simple. Do something somewhere in the middle.
As I read through the IMS, I started to think of a Rube Goldberg machine and the OK Go video titled This Too Shall Pass. Rather than reading a very straightforward schedule, identifying all of the deliverables and a decomposition ad nauseam, I saw a schedule that both inveigled and obfuscated. A Rube Goldberg machine is the perfect analogy for this schedule.
A Rube Goldberg machine is irreducibly complex. It is a single system which is composed of several interacting parts, and where the removal of any one of the parts causes the system to break down. If one component is missing, the machine doesn’t work; the whole system is useless. This is NOT how an IMS should be written. I see a schedule as a tool of transparency. It is a way to communicate if a project is on time in a passive manner. A fully resource loaded (properly decomposed) schedule can help you do a lot of other things. But 5000 lines? I don’t think so, not in this case.
Yesterday, I was having coffee with Jesse Fewell and we discussed, among other topics, how the PMP® or Certified ScrumMaster (CSM) credentials legitimize many in the eyes of stakeholders. This is a sore spot for many, particularly for me. Experience and project leadership trumps a certification any day of the week. But, for those of us who believe we know what we’re talking about, a credential is sometimes a necessary evil. As I advise a Federal PMO on a multi-year project, I have grown to accept that progress can be slow and expensive. Things can be so slow and expensive, we rarely get to see actual value delivered. Rather, successes are measured with earned value. Sometimes, I think it’s just the nature of the beast. But, it doesn’t have to be that way.
You can only imagine my excitement when a vendor proposed using Agile to deliver the next (year) software increment. The PMO I advise has many PMPs but only one CSM…me. I’m not going to go into the details of the project. But, how could the opportunity be seized to leverage Agile? Rather than answer that directly, I’ll ask a question. If you believe in the Agile Manifesto, how would you convince people with no experience with Agile or Scrum (but lots of experience with the PMBOK and Waterfall) that you know what you’re talking about and that Agile is a viable option? I would propose that you make sure you can communicate with stakeholders in a language they understand. If you start using terms like Sprint, ScrumMaster, and Burndowns, when they understand contract periods of performance, project managers, and EVM reports, you may lose that essential stakeholder buy-in.
One of the first things I would recommend you say is “Agile is actually in the PMBOK”. If your stakeholders are PMPs and they believe the dogma of the PMBOK, you’ll have their attention. It’s not called Agile but it is there. In Chapter 2 (Project Life Cycle and Organization) of the PMBOK, you’ll read about Project Phases, specifically phase-to-phase relationships, and then even more specifically the iterative relationship.
…only one phase is planned at any given time and the planning for the next is carried out as work progresses on the current phase and deliverables. This approach is useful in largely undefined, uncertain, or rapidly changing environments such as research , but it can reduce the ability to provide long term planning. The scope is then managed by continuously delivering increments of the product and prioritizing requirements to minimize project risks and maximize product business value. It also can entail having all of the project team members (e.g. designers, developers, etc.) available throughout the project or, at a minimum, for two consecutive phases.
For the Agile pundits out there, does that sound a little familiar? For those who believe the gospel of the PMBOK, is it reasonable to believe Agile is an approach that can be considered? Agile is not a bunch of voodoo for the wild and undisciplined. It’s an excellent opportunity to deliver value.
When I was in the first grade, those were the first sentences I remember reading. I remember being frustrated by this because this isn’t really how we talk. Well, actually, it isn’t how I talk.
I suffer from a self-described affliction called over-descriptivitis. I can’t help but elaborate on any and every idea I’m trying to articulate. I never thought it was a problem. I merely communicate the greatest level of granular detail to my recipient and allowed them to filter out the extraneous information. If my wife asks me what I did at work today, I will tell her everything in chronological order. TMI?
My wife is very forgiving when it comes to me offering more than she asks for. Sometimes she just puts her hand up and asks, “can I have the abridged version?” My over-descriptivitis was even addressed in our wedding vows.
I promise I will tell you the time, not how the clock was built.
So,what’s the point I’m trying to get across? It’s about articulating requirements. It doesn’t matter if you’re using shall statements or user stories. You need to go into enough detail that the person reading it understands your need(s). After you decide on your format, try to be consistent.
Formal shall statement format: The [activity] shall [desired outcome]
Project Management | Derek Huether | July 21, 2010 | 
Comments (1) 
Communications, Negotiate, scope management, Stakeholders, Video
