Blog - Order In The House

Part 1: User Stories – Keeping projects green

Fixing “red” projects is never anyone’s favorite thing to do in consulting. The client is not happy, the team has low morale, your budget is off and the most senior people are usually brought in to help address issues. In my experience, the root cause of most red projects is because standards have not been set, shared and signed off by the client. In this blog, I’ll explore the Definition of Ready (DoR) what is best practice and where the “gotchas” lie.

CORE DEFINITION
In a sentence, the DoR is defined as backlog items that are immediately actionable by the development team for the upcoming sprint and are sized so that they can be “done” within the sprint.

MAIN GOAL OF THE DOR
It provides direction to the project team and stakeholders of a common understanding regarding what makes up a quality user story that can be developed during a sprint. thereby reducing the risk of scope creep, confusion, and project discord.

There are 3 main elements to the Definition of Ready. They are:
1. Use the INVEST acronym as a best practice
2. The User Story structure
3. The Acceptance Criteria structure

1 INVEST ACRONYM:
In 2003, Bill Wake created the INVEST acronym (Independent, Negotiable, Valuable, Estimable, Small and Testable) to help teams access the quality of a user story as it is close to being completed. The definition of each of the letters of INVEST are below.

Independent: The story is independent of all other stories. And for the most part there are no dependencies between stories to allow flexibility of scheduling and development. Technical debt stories or Enabler stories tend to be the exceptions.

Negotiable: The feature being designed is not an absolute contract. There is flexibility to allow the scrum team to determine the design of it.

Valuable: The story demonstrates measurable business benefits and enables easier story prioritization.

Estimable: Include enough information so the team can easily estimate the story size.

Small: Smaller stories have less variability than larger stories. In addition, the story must be able to be done within the sprint in terms of capacity.

Testable: The story must be detailed enough so that test scripts can be easily written and are specific.

2 USER STORY STRUCTURE:
Surprisingly, I’ve seen user stories not follow the standard format, defined by The Agile Alliance. A key point is that the stories must be written in business terms easily understood by the Product Owner and other Business SMEs, avoid technical language and use business terms. The standard structure is as follows:

Structure	What to write	What NOT to do
As a . . .	Name a role here. This should always be a persona, not a system.	A system is not a role. Think about, the underlying need of who needs this needs this information, and that is the persona which should be listed.
I want to . . .	Insert the action here. It always begins with a verb.	Use the INVEST acronym when writing this portion.
So that I can . . .	Insert what is needed here.	Use the INVEST acronym when writing this portion.

3 ACCEPTANCE CRITERIA:
The single most common element I’ve seen missing in User Stories are Acceptance Criteria. This criteria is the definitive definition of the functionality in how it will be accepted by the client. AND, the great thing about it is that the language can be used as part of the Test Script. The easiest way to remember the format is that it’s: “Given, When, Then”. Below is detail regarding the structure.

Structure	What to write	What NOT to do
GIVEN, the user . . .	Doing a thing The need behind the I WANT TO portion of the user story.	Stick with the INVEST acronym when writing this portion.
WHEN, the user takes . . .	An action. This is specific to the user story.	Stick with the INVEST acronym when writing this portion.
THEN . . .	Describe how the functionality developed will act very specifically.	Be EXTREMELY careful here, DO NOT introduce additional functionality, it should be in line with what is in the user story, no more, not less. If your client wants additional functionality, it should be a separate user story.

IN SUMMARY
Following the Definition of Ready and the guidelines above will add stability to your project. And stable projects mean happy customers and employees.

In my next blog post, I’ll explore some additional best practices to explore when writing User Stories.

What is and is NOT a sign-off in projects

Cascading and documented sign offs are core to successful projects.

Talk to any consultant and ask if they have received sign-offs for project deliverables, methodology stages or the project. Most of the time you will hear, “yes”. If you dig deeper and ask to see signed off emails from the sponsor, project manager or key stakeholders, you will probably hear something to the effect that it was a verbal acknowledgement.

Verbal sign-offs don’t hold up when projects go red, or worse.

Cascading and documented sign-offs consist of obtaining email sign-offs first for each deliverable in a stage, then an email sign-off for each stage, and finally a sign-off for the project. In obtaining these sign-offs, you reduce the project risk enormously and more importantly, client satisfaction is high.

The diagram below, is a general example of cascading sign-offs.

What is a deliverable sign-off

Most documents go through a revision or two with the client. When the deliverable is final, the project manager should email it to the authorized people at the client and in the email ask them to reply with sign-off/approval of the document.
This email must always have the deliverable attached.
Once the client replies “I approve or I sign-off”, the project manager must save the email as a PDF and store it within a central server/repository at both the client and within their own company’s drive/server. The PDF is crucial because it will display the timestamp of when the document was sent and when sign off was given.
The Project Manager should always note the sign-off in the weekly status report.

What is a stage sign-off

Each deliverable sign-off within a stage, should be used as successive evidence which can be used to support the stage sign-off. This is done by listing the deliverable name, date of sign-off and who signed off within one of the documents listed below. Links to the repository showing the final sign-off emails and the deliverables are excellent ways to display the information.
Depending upon how your stages are set up, you may already have a document which can be used for a stage sign-off. Some of these documents could include:
- Discovery/Research readout
- All user stories meeting the definition of done
- Final testing results (after defect fixes)
- Go No Go meeting deck
The project manager should always note the stage sign-off in the weekly status report.

What is a project sign-off

The stage sign-offs and the deliverable sign-offs should be used as successive evidence to support the project sign-off.
A best practice is to create a project sign-off document showing the deliverable sign-offs and the stage sign-offs
Show a list of all deliverables, sign off dates and who signed off.

Sign-offs are key to successful projects and done the right way, will reap dividends for your clients, the project, your staff and your company.

Insidious revenue leakage in PSOs

Revenue leakage is insidious. It’s hiding in your data.

When looking at utilization it always affects the company’s profitability. This occurs at PSOs (Professional Services Organizations) of all sizes, however when automated tools are not in place or don’t talk to each other, you don’t know what you don’t know. It’s difficult to find the issues.

The symptoms of revenue leakage include: taking on debt to make payroll, consultants are not available when you expect them to be free for new projects and your managers spending countless hours trying to figure out the issues which ends up superseding sales or delivery work. And this compounds your profitability concerns.

PSA (Professional Services Automation) tools that can show the baseline forecast of both a consultant and a project, their actuals and the consultant’s goals, go a long way to help you uncovering issues. It keeps your managers out of spreadsheets and more engaged with underlying data, so they can prevent profitability issues.

Not every consultancy is ready to invest in a PSA. However uncovering revenue leakage is a core competency of all PSOs.

Some initial items you can investigate are:

What is the utilization rate (in hours) for a given staffer per week?
What is their week-to-week billing hours?
In newer consultancies, many people are a “jack/jill of all trades”. So they’re doing both sales and delivery. This should be part of your review, in what are they doing to bring profitability to the company.

Overall, depending on where you are in your journey as a PSO, your utilization rates will change. The good news, as long as you can obtain the data, you can uncover the issues.

Interested in learning more for your professional services organization? Contact me at [email protected]

MSAs and “hidden” requirements

Congratulations, you have won the contract from your prospect/client!!

A signed SOW (Statement of Work) holds most requirements for your project. However, the MSA (Master Services Agreement) can sometimes include additional obligations that will span any contract between your company and the client. A thorough understanding of both will help you manage risk throughout your engagement.

Every company (client and consulting company) have unique ways to approach a MSA and then SOW. Some put the Ts and Cs (terms and conditions) in the MSA entirely. Some have basic Ts & Cs in the MSA and the remainder in the SOW. Sometimes there is only a long SOW. Whatever your company approach is, ask for the signed legal documents related to the client.

Below are 4 areas typically seen in a MSA that can affect a project and the profitability of it.

Deliverable and/or work process?
1. Review process: How much time is needed for each deliverable
1. Approval process: Approvers and potentially the sequence. Security and Data Privacy often require additional approvers (and time)
1. Best practice: plan your time accordingly
IP ownership
1. What is included and potentially not included in IP ownership through the course of any given project
1. Typically, these are the deliverables noted in the SOW. However, tools, software that your consulting company has developed may be excluded.
1. Best practice: Discuss with your client at the project onset.
Warranty
1. Period of time and scope of what is included in the warranty.
1. Best practice: Good QA will keep this to a minimum. If the client elects to invoke the warranty, it has the potential to drain time from resources who were on the project (and have moved onto their next project). And that affects the profitability of the warranty invoked project and and could cause major issues in the project where the consultants moved onto. In many cases you may not be able to charge your time for the warranty invoked project. Check with your legal team and keep delivery leadership abreast of work, concerns and progress.
Termination
1. How much notice by your company or the client must give if a decision is made to stop the project.
1. Best practice: Commit the termination notice timeframe to memory. Typically, you can keep working and billing during this period. It protects your services organization. Check the language and if it’s unclear, speak to your legal team. Knowledge transfer and finalization of current deliverables are typical during this period.

Interested in learning more for your professional services organization? Contact me at [email protected]

5 items to check before your project starts

Project starts always create excitement, a bit of nervousness and anticipation. Starting on the right foot will help the team feel confident and express this toward your client. Below are five elements which are key to starting strong.

Who owns the budget? (IT or business)
- WHY: This will help you start to identify key Stakeholder(s).
- BEST PRACTICE: If it’s not clear, speak to the salespeople involved in the contract.
Who was involved in the redlines for the scope elements of the SOW? (Obtain specific names and roles)
- WHY: Determining who was involved in the SOW editing will tell you who knows the details of it. This is not to say others aren’t aware of it or haven’t read it. It will give you insight into some of the client’s knowledge.
- BEST PRACTICE:
  1. Ask the client PM who on their team has read the signed SOW.
  2. If it has been shared with the key stakeholders in both IT and the business—that’s wonderful! If not, ask the client PM to share it.
Do you have the week-by-week resource plan for the team?
- WHY: Knowing the details of what roles are billing, the start and end dates, and how many hours per week will help you to understand the financial baseline.
- BEST PRACTICE: Obtain the spreadsheet file from the person who scoped the project. Check it to ensure it matches the SOW. Make a duplicate, edit as needed and use it to manage the financials.
Is there language in the contract for the weekly hours expected by various client roles?
- WHY: In most projects, time will be needed from various client roles to complete the project. Usually there is a rule of thumb for different roles (i.e Product Owner, Key Stakeholders, Business SMEs and Technical SMEs).
- BEST PRACTICE: In the start-up period of the project, set expectations for the time needed by each role with the client PM. The hours will most likely vary during different stages, so be clear about it.
What are the listed deliverables and acceptance procedures?
- WHY:
  - These should be part of your project plan. And in terms of document deliverables, obtaining alignment on the deliverable document format, document size and the number of maximum review cycles with the client PM should be one of your first tasks before the project commences.
  - Endless review cycles will take up more hours than you have budgeted. If you get pushback, bring in the people that scoped the project and/or person responsible for the client’s success and ask them to help intervene.
- BEST PRACTICE: Within a spreadsheet or a table, list all deliverables, the format (i.e. PDF, Spreadsheet, PPT, etc), approximate length and maximum number of review cycle and the time length of review cycles.

Interested in exploring further details to successful project starts, email me at: [email protected]