In today's template files, we explore three templates related to the initial planning of a project. While not all three have to be used, they certainly can be. We discuss who the beneficiaries of the templates are, and how they can be leveraged early on in the project discovery phase.
Why are we including three, when you probably won't use all three? Well, they are related in a lot of ways but can be different, depending on how they get used.
I have talked with a number of people about the importance of having a thorough and robust planning phase built into their project team. Planning, as it seemed, was the antithesis of a properly implemented Agile system. What's worse is that some claimed that it is Agile, since Agile describes the work being done, and not the work being put into it to get the project working, therefore, extensive planning is 100% Agile.
In both cases, planning documentation tended to get ignored. To me, that shit runs contrary to both of their arguments.
In previous template articles, we discussed the importance of templates, and how they can save time and money in your project, as well as eliminate needless back and forth. Further, it's an important aspect of knowledge management, which is something we are planning on discussing in a future article. For now, let's get started with planning documentation.
The Project Proposal Template
The purpose of the project proposal template is to capture vital information that will assist in the next step in planning. We'll give a brief explanation of each section, and cover how this can be used moving forward.
The Header
Information in the header is pretty straightforward and is for the most part covered in other articles. In our template, we include "affected division," however this can be updated to any descriptor that covers who is being affected. For example, you can have "affected customer base", "affected teams", etc.
As with other explanations, the header information should be consistent across all documentation, in order to quickly link associated documents
Opportunity
Also called a problem statement. The opportunity shouldn't be phrased as a solution, but instead worded in a way that allows readers to understand what is happening currently that has led to the project being undertaken. For example, "customer retention specialists are forming a cannibal cult in between calls," rather than "we need to have a safeguard to stop customer retention specialists from forming cults.
Why is this important? Well, it can inform the conversations later on. Let's say we bring in a database engineer to review the project, so they can offer insight. By knowing what the opportunity is, they can better understand what is going to be needed from a database perspective, and begin to form questions about what data they will need to collect and in what forms.
Project Description
The project description is pretty straightforward. This is where you can place the intended solution (your stop them from creating cults statement). The description should be short enough that it's easy to parse the important information, but descriptive enough to eliminate all ambiguity.
Success Criteria
Please do not confuse this with "acceptance criteria" or "definition of done." Remember, this is a planning document. The success criteria should cover what the client envisions as an ideal output from the project. This can be broken up into as much or as little detail as your pretty little PM heart desires.
For example, for one project team, we needed to capture both the expected success criteria and the "blue-sky" success criteria. For those who are unfamiliar with "blue-sky" success criteria, the concept came from a discussion with an Imagineer for the Walt Disney Corporation. He described it as "if there was absolutely no limit to what can be done, what would you like to see." That is, ditch the cloud spotter mentality, see the limitless blue sky, and shoot for the absolute limit. Why would you do this? Well, sometimes things that might seem impossible are significantly easier to implement from the outset, or in a surprising number of cases, can be implemented as a consequence to work that is already being explored as part of the success criteria.
Success criteria is a way to understand what the end goal is, without committing to any work (that is why we don't call it a definition of done, or acceptance criteria).
IT Departments Needed
We were criticized (rightfully), for taking a more software engineering-centric view of project management. So it might be easy for some to see "IT departments" and immediately glaze over with unfathomable boredom, but stick with us.
While software projects would definitely benefit from knowing what IT departments (or teams) would be involved, there are also potential benefits to calling this out for non-software/IT work as well.
A former client of ours had a situation that we initially thought was fairly unique (turns out we were wrong). Their IT team had a special group of talent that managed their internal wiki and knowledgebase. Because the team was using Wikimedia's open-source wiki software, there was a serious concern that allowing individuals with very little knowledge of how it worked access to it, could create serious issues. As a side note, this wouldn't be the case if it were properly implemented, but the company was being extra-cautious, which is fine.
So this team needed to be involved with virtually every project they implemented, as it would be necessary for them to update the documentation and knowledge base. In their case, having this was a way of determining if there was existing documentation that should be updated.
Who Will Support This Functionality
Okay, let's start thinking long-term. Before we even start work, having an idea of who is expected to support this new thing, post-deployment, is absolutely vital. We need to know if these individuals will need to be trained prior to deployment, or if they need to have special access.
This can be very easy to forget, especially when a single team handles all support, like a help desk. Capturing this info is a quick way to know if they will need support so they can support.
First Line of Defense
This is a weird one. The people supporting the functionality aren't always the first person you want to reach out to, should something go wrong. Frequently, there might be a particular team or group that should be the first person to know something is happening, rather than the support team. The reasons for documenting this are the same as figuring out who will support the functionality.
Systems Involved
This can be as descriptive as you like. Personally, I like using bullet points here, rather than a detailed description. Again, this is a planning document, and not meant to be the final document that governs all other documents.
High-Level Workflow
High-level seems to be a contentious term. When we say high-level, we're talking about a view from 30,000 feet workflow. Put yourself in a plane. You look out the window and you can probably tell where there is a cluster of buildings, lakes, geographic changes, farms, rivers, giant balls of twine, etc. You won't be able to determine that within this specific cluster of buildings, there is a McDonald's that still has a play area, that is next to a store that used to be a Burlington Coat Factory, but is being remodeled to be a Spirit Holloween.
That is to say, don't worry about the specifics, just broad "30,000-foot" concepts.
Tickets/Considerations
The final section is one for tickets and additional considerations. These are recent additions to this template and are used to identify anything that directly comes out of the initial planning. Typically we used the tickets section to identify certain work that needed to be done in order to fully move forward. Spike/discovery tickets for example. Again... a planning document... don't worry about being too specific.
Considerations, on the other hand, came out of a desperate need to allow the individual preparing the document to have space to voice concerns or things that might need to be considered like edge cases. This replaced a previous box that was a "conclusion" field. It had only been used to share concerns, so the bulleted list of additional considerations was created (with tickets being separate) so that these things could be shared in a structured manner.
Concluding Thoughts
The project planning document is ideal for a general document that everyone can access. It has enough technical information that your project team can benefit from, but because it's meant as a planning document the client can read and verify the information as well.
The Project Discovery Template
Think of this as the sister template to the project planning template. The primary difference is that this document is meant as a purely technical document. It is for the project team to reference when they need to have insight into the planning process.
The reason we created this document was to alleviate frustrations among the team members. What we have is a more concise breakdown of information, that project members can quickly access.
Project Overview vs Project Requirements
For most, this is pretty straightforward, right? Well, yeah, but I think we all know an overly analytical shit-stick that will argue that these are technically the same thing.
They are not.
The project overview should give a detailed account of everything being done. The project requirements, on the other hand, are a detailed account of what specifically needs to be done.
Let's look into an example.
Project overview: we need to update our call and ticketing system to prevent the customer retention specialists from spending too much time out of the call queue. The ticketing system will also link to the new "Cult Deprogramming System" to automatically flag an agent should they spend too much time out of the queue.
Project Requirements: update the IVR to include a timer for an after-call status. Integrate the IVR system with the ticketing system to track after-call time. Initiate a trigger that automatically flags an agent if they spend more than two minutes in after-call status.
Project Breakdown
We give two examples under teams, but understand that the rows can be expanded out to cover as many teams as needed. For each team, you should document the potential work that needs to be done, and who determined that work would be needed. Why is "who suggested it" included? Well, in our experience, more complicated work might need further discussion, and having this documented will allow the reader to know who to talk to in regard to why this work was suggested.
Project Benefits
Another new addition to our template. Again, we provide two examples, but the rows can be expanded out as much or as little as needed.
Why did we add this? Well, it started out as a request from our QA. They needed a bit of insight into how this would be leveraged when implemented, and knowing these benefits allowed them to better test the work. What we learned post-implementation, however, was that our developers also saw a benefit to it. When exploring the work, it helped to know how their work would impact the client, not only from a coding point of view but also from a social/commitment view as well.
Potential Impact
Initially, this was primarily used to explore strategic alignment. However, it quickly expanded to include things such as edge cases, potential conflicts with other software, and/or side effects of its implementation. Again, be as descriptive as you wish.
Concluding Thoughts
As mentioned, this template is a fantastic, more stripped-down version of the project planning template. It has found success as a more technical document, rather than one that could be used by everyone involved.
The Business Analyst Template
We are now getting into weirdly specific templates. This template was created as a guide for business analysts during the planning and discovery phases.
The template was created with input from 25 business analyst professionals and was compiled into a single list of "questions every BA should ask for every project. We won't be going into any detail about the questions, as they are fairly easy to understand. We will discuss one differentiating factor of the header: net new and change to existing.
From a BA working for an aeronautics software company:
"Personally, I always need to know if something is purely a new addition, a simple update to an existing service, or a combination of both. It will always be at least one of those two things, but sometimes it can be both."
A follow-up comment on this:
"This is a great idea! It happens all the time at {workplace}. What we get a lot is work that will require the ability to administrate various things. The new service is a net new service, but there will be changes to the administrative portal to handle the new service. It's both a new and a change to existing services.
Concluding Thoughts
The BA template, while meant to provide guidance for a business analyst, can be leveraged by all planning members, which is why it is included in our three-document planning template page. Of the documents here, this one will be the most detailed, and indeed, it should be.
The BA template shouldn't in any way suggest that these are the only questions that should be asked but should provide a starting point for further discussion.
Commentaires