Blog - Order In The House

Gotchas in contractual language – words and phrases to avoid

What every Salesforce Partner should know

I hope this headline caught your attention. Today . . . this post is not about 4 letter words. But rather avoiding vague or ambiguous language (some with legal meaning) in contracts. Avoiding certain words or phrases in contract language makes for a more clear understanding of scope and ultimately better client alignment.

I have reviewed a great deal of contracts during my career and I’ve learned to avoid certain terms at all costs because of the potential for negative repercussions. This blog post should be considered general advice, not legal. Always speak to your legal counsel should you have concerns about contract language.

Don’t let this happen to you

Several years ago, a contract my company wrote contained the phrase, “including but not limited to” regarding data. Then a list followed, noting the objects in scope to migrate.

This was an org migration. The project lead said he told the client we would migrate only two years of data because the older data was inconsistent and often incorrect (this was not in the SOW). So the project progressed, the team migrated 2 years of data for the objects listed. The client was not pleased. So much so that they threatened to go to another ISV, if we didn’t “make it right”.

What this meant is we needed to restart the project from scratch, for free.

We had more data model work to do and the client also stated we needed to migrate chatter posts, and field history tracking for all objects except two. It was 3 months of free work, we didn’t have a legal basis to push back (never mind potentially losing the client).

Below are the words I always counsel ISVs to remove from contracts, there are many more. Generally speaking avoid using general acronyms, vague terms or the latest phrases being bandied about in online communities. Speak with your legal representative if you feel you must use them. Every state has their own unique spin and precedents on language.

What to avoid

AVOID THIS TERM OR PHRASE	COMMON INTERPRETATIONS OF TERM OR PHRASE	COMMON MISTAKES IN PHRASING	DO THIS INSTEAD
Ensure	Law Insider: to make sure or certain or to guarantee.	Vendor will ensure <enter text here> . . . to ensure maximum value to <enter client name>. . .	Avoid the word entirely. Be more specific in your language in what you will do AND what the client will do to support the item.
Best efforts or All reasonable efforts	The Law Dictionary: 1.stating that a certain result won’t necessarily occur. Good faith promises that it will get as close as is humanly possible. 2. A high standard that if it isn’t met is excusable. The efforts put forth are all that can be done.	Vendor will put forth best efforts to <insert text here>” During the support period, Vendor will make all reasonable efforts to address issues.	Like the other phrases in this list “best efforts” is vague. Just for that reason alone, don’t use it. Be more specific about the efforts you will take, including what is out of scope.
Including but not limited to	Incorporated Zone: the phrases including but not limited to or such as but not limited to are used to present a list of things to the reader while at the same not excluding other possibilities.	Out of the box Integrations include, but are not limited to <insert items here> During discovery, vendor will review all existing processes, which will include but is not limited to <insert list here>	Speak to your legal counsel, what I’ve counseled is to use the word “including”, and then get very specific.
industry standards	HG.Org: In a lawsuit, the industry standard is usually used to establish negligence or failure to perform under a contract. If one performs at a level lower than the industry standard, the plaintiff may say that the defendant failed to meet the applicable standard, and should therefore be found liable.	Vendor will apply industry standards to the project approach including configuration, code and written documentation.	Rather than use this in a contract, either define what you will do, or state that discovery deliverables will include definitions regarding quality

I hope this blog post has helped you think about contract language and avoid misinterpretations.

I’ll go back to my headline above. “Don’t say &%^@ in your contracts”, and sleep at night.

What’s your real gross margin and the cost of your bench?

What every Salesforce Partner should know

Most SIs calculate project profitability and have a minimum gross margin set for projects. And if the margin isn’t at or above the figure, it has to go through several approvals, or back to the drawing board to make it financially sound. Getting the Sales and Delivery teams on the same page of gross margin is key to the foundation of a successful project, and the details count.

There are so many reasons for a minimum gross margin. The obvious is profitability, but the not so obvious factors are: keeping utilization metrics high for both the individual and their cohort, company month over month profitability and the downstream decisions of whether to hire or not.

In a former position, my team and I reviewed the scope and resource plans of all SoWs. One thing we pushed back on were “roller coaster” resource plans. The reason being is that it affected the bench and therefore monthly profitability of the company. (It also stressed out the consultants because they knew they would not make their utilization number and therefore it would affect their bonus). Enforcing this didn’t make me popular with my sales colleagues. A more balanced scorecard would have put us on the same footing.

In retrospect I wish we had implemented a “probable bench time” calculation (a scorecard of sorts) from the resource plan and arrived at an adjusted gross margin number. The example below shows a project 9 weeks in duration. It also shows calculations of total hours, client rates, internal rates and totals to both. The gross margin is 38.18%.

If we look at the probable bench time for the various roles, the items marked in pink below notate where the consultants would not be able to take on another project because they’ll quickly return full time to this project. My PMO colleagues usually called this “roller coaster” resource plans. The pink boxes total 240 billable hours that are wasted. Meaning, it will be impossible to staff the affected consultants on other projects.

To calculate the effect of the 240 hours on the inability to staff these consultants, you can do the following calculations. See diagram below, also to follow along.

Sum the total hours of the consultants that will remain unbillable. This is short periods of time squeezed in either between FT (40 hours/wk) or PT (20 hours/wk).
Calculate the average rate of the affected consultants.
Multiply the total non-billable hours by the average rate. This is the Cost of the Bench.
Subtract the Cost of the Bench from the project’s Gross Profit (in dollars).
Divide the Project Profit/Cost of the Bench from the Project Cost to the client.
The result of this last calculation will be the Adjusted Gross Margin.

In the illustration below the Gross Profit decreased by 10%, and is now 29.8%. So how do you address this?

Ensure you have an outside SME review the resource plan (not the scoper) and the project scope. When roller coaster resource plans exist, it’s usually an indicator of trying to back into a number for a client. And while sometimes that needs to be done, in the illustration above, the team will end up working beyond their billable hours to get the project done. And consultants who do that, and then don’t get their bonus, quit.

Trim the scope or reduce your rates.

Starting with a standard in how project profitability is calculated, will give confidence to your delivery teams in what was sold and their ability to deliver on it. And Sales can be more effective during the sales cycle in describing the work, how the teams work, and creating proposals.

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 is your client’s ROI of Dreamforce, and how do they prove it?

If your client is attending Dreamforce, they need to justify the cost of attendance. This year Salesforce provided a template to help customers justify their expense when putting in the request to their management team. That is not enough. The people approving their expenses are expecting a briefing AFTER the event demonstrating the ROI.

Dreamforce attendees need to connect the dots between ideas and information learned at Dreamforce with their company’s initiatives and goals.

Order in the House has created a template, you can download and modify for your prospects and clients, free of charge. Make it easy for your prospects and customers to write up their briefing. Better yet, pre-populate it with sessions or meetings they had with your company.

To obtain the form, fill out the fields below.

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].

WHAT EVERY SALESFORCE PARTNER SHOULD KNOW:

Are there issues lurking in your templates that could affect project profit?

What lies below the surface could result in red and unprofitable projects.

Have you had a red project because a deliverable wasn’t comprehensive enough? Did you lose money or profitability on this project?

Now ask yourself these questions:
-Where are your templates?
-Does everyone use the same ones?
-Is there a consistency for repeatable elements of them (i.e. version control section, approval section, summary, table of contents, definitions and out of scope).
-Are they consistently branded and is the client’s name and logo on the main page?

Most consultancies have a mixture of strong templates and those needing improvement.

Here’s a real life example I experienced with a fortune 500 company. It illustrates when hidden “issues lurk in your templates”. I was called in to help fix a red project. Here’s what I found, and the impact on our company.

User Stories

WHAT: The user stories did not contain acceptance criteria.
WHY: A duplicate was made from a prior document the consultant was given. it was lacking in the acceptance criteria and several other key elements that help manage scope.
THE RESULT: Never ending user stories. The client pushed back on what was delivered stating that it wasn’t what was in the user story and they wouldn’t accept what was built. The team kept building and rebuilding.

Test Strategy document

WHAT: A very basic template was used, stating they’d do UAT, but no definitions or processes were outlined.
WHY: Staff used what they had locally. They did not use the template from the central repository.
THE RESULT: Client decided to do whatever testing they wanted when they wanted. They tested items out of scope and reported “defects”. In addition any new feature they wanted was labeled a defect-because there was no clear definition of it.

The Overall Result

Several highly expensive delivery team members and myself were put on the project to turn it around and close it. Our work was all non-billable. The value of the senior staff placed on this project in a non billable capacity was worth more than $700,000. It also meant they could not be put on other projects in a billable capacity.

Comprehensive templates drive consistency throughout your entire practice. This is especially important when you have remote and dispersed teams. Less experienced consultants will see what is expected in a deliverable, and everyone in your practice will deliver consistently. And most important, your clients experience a well delivered project of high quality.

Below are some core elements, every template must include::

Correct branding
Version control log
Approval log
Table of contents
A non technical overview of what the intent of the document is and what is being documented and how it will be used in the project.
Definitions
Diagrams (as needed)
Out of scope section
Detailed specifics for each template type

For qualified consulting executives, Order in the House is offering a free health check of your templates. Contact me at [email protected].

WHAT EVERY SALESFORCE PARTNER SHOULD KNOW:

If your project methodology is a 1 pager, expect red projects

Ask yourself how much depth is there in your company’s project methodology.

A one pager is perfect for Sales decks, but your Delivery team needs more comprehensive material. All team members need to know what is expected of them, what quality looks like and aids in the access of related material.

I worked with a large firm where there was a 1 page Project Methodology. Each partner could interpret what was done within each sub phase. The firm was growing and increasingly staffers from different areas were assigned to projects. Each of the team members had divergent expectations of what should be done. As a result there were misunderstandings as to who does what, what a deliverable should include and what meetings should take place. Clients began to see the disarray. And projects began to creep into the red territory.

In a PMI white paper, Sean Whitaker writes, “a project management methodology is a defined, documented and discoverable set of policies, practices, processes, tools, techniques and templates that provide guidance on how projects are run within an organization”. It is not a one pager.

Salesforce partners must invest in a document and in depth methodology. It will drive consistency throughout your entire practice. Staff members will have more confidence as new teams form for each new project. They will know what to expect of their colleagues and the methods. And most importantly, your clients experience a smoother project of high quality.

A project methodology should include the following:

Details of each sub phase
Meetings
Deliverables
Specific workstream information
Links to templates
Describes how quality is baked into the methodology
And finally, there is a formal training program

The materials for the elements above must be well organized. Each echoing what other areas have already established. Your sales literature should also echo what is established, this includes your SOW templates.

In closing, an in depth methodology is a crucial tool in ensuring the success of your delivery practice.

If you are interested in a free health check of your project methodology, contact me at [email protected]

5 ways to retain consultants in Professional Services

Consulting practices typically have high employee turnover, and this industry is not untouched by the Great Resignation, at term coined by Dr. Anthony Klotz, an organizational psychologist. Much has been written about The Great Resignation, one key reason why people resign, which is common to all types of professional services, is burnout. In an interview with Verse, Dr. Klotz, described several key elements. In describing one of them, he said, “Another factor is burnout; people are emotionally exhausted. It’s a strong predictor of quitting, which makes sense, because the only cure for it is taking a break and replenishing who you are.”

Burnout in consulting typically occurs when the staff are working long hours for a while; 60-80 hour weeks are very common, especially when deliverables are due. Dig deeper into the cause for long hours, and they frequently stem from troubled projects.

“Project management problems become increasingly deadly as a professional services business grows”.
Geoff Mcqueen, Entrepreneur Magazine

When a consultancy is in its first few years, the focus is on bringing in revenue and logos. To make payroll, decisions may be made to take on very risky projects. In Entrepreneur Magazine, Geoff Mcqueen writes, “Project management problems become increasingly deadly as a professional services business grows. While securing bigger and better projects and expanding the business feels great, growth also puts the business more at risk if not managed carefully.”

In my experience in managing PMOs and projects, I’ve seen consultants work long hours on challenging projects. They burnout. In addition there are unhappy clients, and unhappy managers. For the burnt out consultant, it makes it easier for them to answer that Linkedin ping from a recruiter when having a bad day.

Many factors go into quitting a job. More money isn’t always the top priority. Consultants want stable and rewarding projects. The foundation of stable projects are a detailed methodology, templates, training and ongoing coaching.

If you are in a leadership position in a Consulting Practice, ask yourself the questions below, followed by this key question:
“If we had the items below, would we have less retention issues?”

5 elements to keep projects stable (and consultants happier)

Methodology
- Is your methodology beyond a single page or single diagram?
- Do you have details regarding each sub phase?
- Do the details include what meetings must take place, deliverables, roles and responsibilities, and best practices?
Templates
- Do your consultants use what they have used in the past?
- Do people in the same roles deliver differently?
- Are your templates in a central repository?
- Do you have templates for all sub phases? And does the content and language echo each other?
- Do your templates have consistent branding and formatting?
Detailed Best Practices
• Do you have these for each role places on projects?
• Do you have these for the different areas of your practice?
• Do you have the basics, such as User Story Writing, and core definitions?
Training program
- Do you have training program for:
  - Staff new to the company (solid practitioners, but need to know how “your company” does it)?
  - Staff new to consulting (college grads, or even those changing careers)?
  - Staff new to the role (promoted staff)?
Does your sales collateral (decks and SOW template) match the delivery methodology and templates?

If you answered no to even half of the questions, consider focusing on them. Consultants want rewarding projects for their clients and themselves. When a consultancy provides the foundation for this, you will reap the benefits. Contact me at [email protected] if you’d like more information on how to enhance your foundational project assets.

Part 2: User Stories – keeping projects green

In last week’s blog, I described User Stories and the Definition of Ready. Aligning on a Definition of Ready with clients is a key element in reducing scope creep on projects.

There are other elements to consider when approaching User Story development, additional definitions or standards and the overall process.

PROVIDE ADDITIONAL CLARITY
Sometimes a picture is worth a 1000 words. And/or you need to direct the developers easily to the right information via link. Consider these when applicable for your project.

Wireframes, Designs, Diagrams, Links:
If there is a visual element to the story, provide attachments to the approved designs. Examples include:
- Screenshots of functionality to emulate
- Wireframes using specific tools or hand drawn
- Designed documents (typically web pages or elements of web pages) with specifications of colors.
- Process Maps
- ERDs
- Links to any of the above or other visuals

2. Data:
Attach data when you can. If it is a large volume, provide a link or path to find it for the developers.

ASPECTS OF FUNCTIONAL AND NON-FUNCTIONAL REQUIREMENTS
The items below will help define more information for each user story.

Functional Requirements:
Definitions of project terms and ways to mark up stories will help the team understand and find user stories. Consider the following two items below.
- If you have a project dictionary or glossary including certain functional terms, add them to the story if it will help provide clarity.
- Some applications have functionality to add tags or custom fields with different picklist values. These will help you organize and add more information to the user story.

2. Non-Functional Requirements:
Something that can often come up in requirements are non-functional requirements. For example, all code must work in specific versions of Chrome, Safari and Explorer.

Or there are performance requirements for how fast a query must return results. Or even how the system will be protected from hacking. Add or attach these when needed.

AVOIDING POTENTIAL ISSUES IN THE USER STORY PROCESS
Below are some tips to consider throughout the life of a user story.

Tracking what is sent to the Product Owner (PO) and what is approved by the PO.
If using Jira, Trello, or other apps, ensure you have 2 statuses marking when the story is sent to the PO and when the PO approves it. These statuses could be something to the effect of:
- Sent to PO
- Approved by PO
Avoid changing the Definition of Ready mid sprint.
Be clear that your project’s Definition of Ready, should not be updated during the sprint. To do so, would add points to each story and the team is likely not to complete the sprint.
Beware the never-ending user story.
This can occur in several places during the sprint.
- If the client wishes to iterate on a User Story after it’s been approved, create a new story and put it in the backlog.
- If during the Sprint Review/Demo, the client sees the functionality, and it spurs on additional ideas (enhancements), jot them down, and state that they can go into the backlog for a future story (and perhaps for the next sprint).
- Once the user story is approved by the PO, if you can lock down the record from editing by anyone on the scrum team, do so. The purpose of this is to ensure a “well-meaning scrum team member” does not change the scope of the story midstream. If you can’t lock down the user stories, save a PDF or screenshot of the approved user story (get the date and time in the screenshot too).
Projects with multiple scrum teams:
If a project has multiple scrum teams, each one must align to the same Definition of Ready, Definition of Done and how they estimate stories. This is to ensure there are aligned standards. When there are multiple scrum teams, clients tend to start comparing one team to another. Below are some of the scenarios that can play out if they’re different:
- If the different scrum teams calculate points differently, they’ll ask why one team does more work than another.
- Or if they have different Definitions of Ready or Done, clients may ask why one team has more defects than another (and it could be because one team’s definition is not as stringent as the other’s.

These illustrations demonstrate what not to do, so that you can prevent them so your project runs more smoothly, and your client has a good project experience.

I’ve run into all of these scenarios in my years of consulting and project management. I hope this blog saves you some of the challenges I faced, so that your clients and teams have stellar experiences.