Project Manager - Order In The House

5 Ways to Avoid The Illusion of Agreement

What every Salesforce Partner should know

Illusion: Macmillan Dictionary: “an appearance or effect that is different from the way that things really are”.

Finding out a project team had the illusion of agreement for a core portion of scope can be devastating for the team, client and project. It breaks trust immediately, like a resounding door slam.

Oftentimes this starts with interpretations of certain words. Most often it occurs because assumptions are made and insidious change occurs. The illustration below humorously shows how different stakeholders understand a swing (as a metaphor for a software implementation).

The conflicting assumptions, expectations and interpretations are the core to the illusion of agreement.

In my twenty-five years of project experience, I’ve learned to stay in front of potential assumptions. Additionally, when I managed a consulting PMO, I made it a point to counsel the project managers to do the same. Because the alternative, when the project turns red, erodes trust between the client and the consulting company. And people spend days and days working through the issues.

Below are the top 5 areas where I’ve seen the “illusion of agreement” in my own career. And what to do to lessen the potential for different interpretations between your company and the client.

1 The illusion: Key stakeholder’s opinion of the project scope

SCENARIO: Early in my consulting career a new key stakeholder (new hire) was introduced to the project at midpoint. She didn’t attend discovery sessions (despite escalations), and when she finally showed up for a large meeting, she found the project’s scope did not include some of her department’s goals. Let’s just say it was not a fun meeting after that realization. And there were a couple of weeks of challenges.

HOW TO AVOID: Map the client’s business outcomes/goals to project goals. These should come from the project sponsor and/or key stakeholders. Must be documented and signed off. Then review them in detail with any new stakeholders as the project continues.

2. The illusion: All client documents are in scope

SCENARIO: I’ve seen client project team members share a boatload of documentation into a shared drive. They assumed everything they gave us was in scope, even if stated in the SOW that something was out of scope and was also outlined as out of scope in the kickoff meeting.

HOW TO AVOID: Maintain a client document log, and map them to the scope (simple spreadsheet) If out of scope, state that. Review this document with the project team.

3 The illusion: User Stories are locked down vs User Stories can evolve

SCENARIO: I’ve seen this occur when the consultants assume the user stories are not being edited after approval. And the client team assumes it’s okay to edit stories throughout the project so they meet their needs.

HOW TO AVOID: Establish the Definition of Ready and Definition of Done for User Stories early in your project.

4. The illusion: A complex technical specification is misunderstood by a client

SCENARIO: A client signs off on a Tech Spec, the solution is delivered and they’re very unhappy with the result.

HOW TO AVOID: Every Technical Specification should include a description of what is being coded in layman’s terms. The spec should also include diagrams (wireframes are good). And always Include assumptions and and out of scope sections. Finally obtain a sign-off on the document.

5 The Illusion: How functionality should look and work

SCENARIO: Something most consultants notice is many of their clients need to see a visual of the functionality to understand it. I’ve seen sprint demos save the day to obtain alignment or if not aligned, you’re at an earlier stage to address it more quickly.

HOW TO AVOID: Do demos in every sprint. Record the demos and share the recording.

I hope these items help you and your team to proactively stay in front of project assumptions.

If you’re interested in learning more, please contact me at [email protected]

What Every Salesforce Partner Should Know:

Project management certifications don’t always equal high quality projects.

Project Management certifications don’t always equal high quality projects

A PMP, CSM or even a SA certification don’t necessarily make you a good project manager in consulting. It is a criteria recruiters screen for, and can eliminate some very good candidates. Don’t get me wrong, these certifications enable project managers to use a common language and employ standards recognized worldwide.

If you google “Project Manager traits”, you’ll find 100s of articles, stating roughly the same qualities (strategic, organized, change agent, etc). Generally speaking, I’ve found the descriptions of these qualities general. In this blog, I’ll describe in detail and with examples what a good project manager does in consulting.

In a prior blog post, I wrote about the need for Project Managers with proven Salesforce expertise because in the Salesforce ecosystem every project is highly customized. Two other core traits that I look for in a great project manager are proven technical experience, a high EQ and intuitive foresight.

Over the course of my career, I have counseled project managers to step beyond the traditional PM role, determine what is the question behind the question from the client. And stays very close to the project architects and asks them throughout the project what are the risks and, what keeps them up at night.

When coaching PMs, I’ve come across the following:

Example 1: A very involved client IT team.
Before security testing, I counseled the PM to have the TA create a document describing false positives. It detailed what may occur, why it occurs, and why the system is safe. This allowed the project to stay in front of the “defects” that might be logged, and gave the IT team the confidence that we were one step ahead.
Examples 2 & 3: Proactively prevented UAT Scope Creep.
2. Always use a Traceability Matrix. I counsel PMs to always use a traceability matrix. It maps the User Stories (with Acceptance Criteria) to the Test Scripts, which are in turn mapped to the Test Results. Using this, the PM and Architects can quickly identify new requests disguised as defects, and as an added plus, you ensure everything is tested. This makes testing so much smoother, and again gives the client confidence in the team.

3. Establish Test Triage Process. When using a Traceability Matrix, you must also implement a Test Triage process. At one unhappy client, we found during testing there an immense amount of duplicate defects. And therefore, it made the bug count higher than the actual. Managing the project sponsor became a full time job because they were so upset with testing. Once the PM implemented a strict test triage review process (and detailed test reporting that I knew would give the project sponsor confidence), the defect count dwindled to a very manageable level.

When I interview PMs, below are some of the characteristics I look for in consulting Project Managers. I craft questions or scenarios to gauge their breadth and depth. And most importantly, you have to phrase the question so you don’t give away the “typical best answer”.

Flesh out the EQ of Project Managers
This is about behavioral questions, and be extremely careful how you word the questions, so that the answer isn’t obvious. Ask how they learn the political landscape at the client. And the answer should be more than a debrief from Sales. In a post on the The Project Management Academy website, they write: “project managers with strong emotional intelligence understanding handle larger projects successfully with more people better than those with less emotional intelligence knowledge.” I could not agree more.

Determine the breadth and depth of their technical knowledge
A PM who states they have been on projects with data migration, integration or code, is not enough. All PMs have been on these projects. But not all projects are successful. Ask them what must be established to keep risks in these areas to a minimum. And expect an experienced somewhat technical answer. Then you’ll know they know.

Great PMs have foresight
They are always 10 moves ahead in the project. Most PMs will say the project plan keeps them on track and keeps them ahead of tasks. But your question.needs to be about the nuances of foresight. For example are they volunteering the following information:

Always has daily internal stand ups, not to discuss user stories, to work through who is doing what, who needs help, alignment to forecast, concerns, etc
Has a weekly forecast discussion with the team and updates the forecast by discussing the work and realistic hours.
IDs the riskiest elements of the project, and start working on them immediately in collaboration with the architects.
They read every project document, no matter how technical and work with the team to ensure it aligns with the timeline, scope and budget and it is clear and of high quality.

When hiring or promoting staff into a PM role, consider the above. And don’t let the lack of project management certifications eliminate good candidates.

What every Salesforce Partner should know:

Positioning Project Managers during the sales cycle when clients object

It’s a fact in consulting, many small and medium size clients don’t want to pay for Project Managers. Clients will say any or all of the following:

They will manage all of the PM work. And your team should be able to manage themselves.
It was assumed the Sales Engineer will do the PM work for free.

Ultimately the client doesn’t value what a project manager does on your projects. And the downstream effect to a professional services firm is insidious. I’ve see all of the following occur and it negatively affected profitability and revenue.

The Sales Engineer was taken out of some sales cycles. And that slowed down the pipeline, and paying clients.
The Sales Engineer was pulled into too many directions. She/he did not have enough time to manage the project. And so some risks were unidentified, and worse, they turned into issues. The project went red. The client was unhappy, as was the team.
The client stated they would not pay for the issues. And to save the account, free work was done. That degraded the profitability of the project. And the ability to place those consultants on other projects.

When you perform work for free, it reinforces to the client that it’s less legitimate work, that your time isn’t worth their money. Because they don’t value your time, your skills, or your expertise, they will expect this as “business as usual” going forward.

Below are some techniques to first embed in your project organization and how to deflect objections during the sales cycle.

PROJECT ORGANIZATION

Don’t label the PM role a Project Manager. Instead use Technical Lead or Solution Lead as the role name.
If you share a resource plan or listing of roles, put the “PM” role near the bottom of the list. It should never be first or second. This also applies to any sales collateral used during the sales cycle containing this information.
A Technical/Solution Lead, must have proven Salesforce expertise. So in addition to the PM work, the person in this role must do the following:
- Have the Salesforce Admin or Platform certification and have done some configuration.
- Attends the majority of discovery sessions, contributes notes, assists in managing agenda and scope throughout.
- Leads or co-leads at least one of the discovery sessions.
- Has a large role in the Test Plan.
- Joins all test triage calls, and ensures the processes and definitions are followed.
- Attends the end user training sessions and answers questions about Salesforce that the Trainer can not answer.
- Manages the deployment plan document and ensures it’s in order, thorough. Adds data where needed. Updates the document during deployment. Runs any deployment check in meetings with the client (along with the consultants who are doing the deployment).

SALES CYCLE

In using the project organization elements above, it should make things easier for the Sales Team to overcome most objections. That said, some clients will continue to push back. Below are some techniques you can use during those conversations to overcome their concerns.

As usual when dealing with objections, validate and empathize what they have said, you understand them, and show gratitude to the prospect for bringing the objection forward.

SITUATION: If the prospect states, THEY have a PM who can manage the project. Ask for a deeper understanding of their concerns and why.
- ASK if their PM has a SF Platform or Admin certification and experience configuring SF.
  - CLIENT’S ANSWER: The majority of the time this person will not have a Salesforce certification and the client will state they’re very good at their job and have managed other projects. They will probably say this person will have the certification by the time the project starts.
  - EXPRESS: That the timeline and therefore cost assumed a person with the cert and experienced skill set in this role.
- ASK if their staffer has implemented a project with a hybrid methodology such as the one specified for this project.
  - CLIENT’S ANSWER: They will state their staffer is exceptionally talented and can handle any methodology.
  - EXPRESS: Mention that detailed knowledge of how your projects are run was assumed. And this familiarity was embedded into the quote. Knows what has to come and when, gating items, internal quality controls, etc.
- ASK if their PM has run the following meetings
  - Discovery meetings (and name some of the functional areas)
  - Run the salesforce demos (hands on).
  - Run test triage
  - Has run Salesforce training sessions and answered additional technical questions during the sessions.
  - Has experience managing and doing deployment
  - CLIENT’S ANSWER: They will most likely negate the need for the PM to do this and that the rest of the project team should take this on.
  - EXPRESS: The quote was designed for someone to do the work and the hours would need to be done by someone and that the other roles do not have the bandwidth to do this work.
- ASK if they have written and managed the following types of deliverables (again these should not be the standard pm deliverables).
  - Test Strategy Plan
  - Deployment Plan
  - CLIENT’S ANSWER: Give us the templates and coach us on each one, and our PM will be able to do this.
  - EXPRESS: The project quote did not include hours for this. (And chances are they will not bring up coaching of this work, and if not, mention it). Our team has seen many final deliverables and they know what complete and good ones must detail.

2. SITUATION: If the prospect states, THE SALES ENGINEER CAN MANAGE THE PM WORK (for free) or it’s not needed.
- ASK: for a deeper understanding of their concerns and why.
- CLIENT ANSWER: It’ll only take a few minutes of your time. Or, there is a lot of future work.
- EXPRESS: I’m glad you see the value in how we work, and how it will bring project success. And that success will translate into business success. That’s core to how we work with clients. Many of our competitors will put anything on paper just to sign a client. In their wake, they leave failed projects and disappointed customers. What we do is ensure every one of the project team members have considerable and proven, technical Salesforce expertise. This is core to how we deliver successful projects and the reason why we score XXX on our NPS surveys and have repeat business.

SUM UP YOUR COMMENTS ABOVE:

Our Tech Leads are just that, technical leads. They have experience with configuring Salesforce and maintaining their certifications. It’s mandatory.
Also the project was scoped so that our team does not have to explain how to run sessions, provide templates, explain templates. They’re expecting this person to be an experienced technical resource.
If they still don’t want your staffer, you’ll need to explain you will still need to add extra hours to the project so that your project team can take the PM through each item as they come up. It could cost more than adding the PM to the project.
Lastly if they still push back, know that this will be a VERY CHALLENGING PROJECT if you move forward without a Technical Lead. They’re not taking your statements seriously, consider walking away. It will not be a profitable project and it could affect employee attrition.

If interested in discussing further, direct message me at: [email protected].