IT Project Poster
Too many IT projects start with a solution in mind, then reverse-engineer the rest. Flip the script and envision your project from the ground up.
USE THIS PLAY TO...
Iterate on the strategy and scope of your project
Start off with a clearly-defined problem and solution
Keep stakeholders up to date
If you're struggling with Health Monitor, running this play might help.or on your
4 - 8
3x 45 min sessions
Project posters get filled out over the course of several sessions with your team, so don't worry about doing it all in one go. In the first session, focus on defining the problem space. Then share it with your stakeholders as early as possible to get their feedback, which you'll incorporate in future sessions as your project develops.
The poster is split into 3 parts to support this evolution:
Define the problem – Explain why solving this problem matters to customers and to the business. Get clear on objectives, possible solutions and who and/or what is affected.
Work through a solution – Develop possible approaches and agree on the best solution. Articulate how you landed here, what success looks like, and how other systems and teams will be impacted.
Ready to go – Map out your milestones, focusing on delivering iterative customer value and make sure everyone on the team knows their role as you prepare for kick-off.
HOW TO RUN EACH SESSION
Schedule 60 minutes with your team. Collect and share relevant information in advance (e.g., notes from user testing, analytics, customer feedback, market research, etc.).
Start the first session by sharing the project poster template with instructions. In future sessions, you can start by (briefly!) reviewing what's changed on the poster.
Lead your team through the questions, making sure you're basically agreed on each one before moving on to the next. If you reach a stalemate or team members have wildly different ideas, take the time to talk through them and try to reach a consensus. If you can't, someone from the team should take on a follow-up task to gather more information and share it out. Ultimately, the project's full-time owner (i.e., project lead) or executive sponsor may have to resolve differences of opinion by simply making a call on which direction to go.
Define the problem
This part shouldn't take more than an hour. Get a few people together to lay out the high-level view of your project. Include just enough detail that someone outside your team can understand why you're doing this project and its objectives.
What is the problem: This area should be a clear and succinct statement of why you are trying to solve this problem and who will benefit.
Possible solutions: Brainstorm as a group the possible ways of solving the problem you just defined. This part can easily take hours, so use a timer to force yourself to spend no more than 20 minutes on this section. The result should be a statement of the solution all are leaning towards and a brief summary of potential alternate paths.
Teams affected: At this stage, keep it high level. The purpose is just to understand who you should involve in the next steps as you get more specific about your project.
Work through a solution
Now it's time to get more specific about your project. Using the first part as a guide, start to build out some of the details of your project. This isn't a full-on project plan at this point, but will serve as a roadmap for a detailed plan later. Make sure to involve your stakeholders and other adjacent teams as you evaluate and co-design possible solutions.
Solution details: Go into more specifics of the solution you have chosen and what you will deliver along the way.
Validation: What questions did you have to answer to come to this solution and what data or other information did you use to answer those questions. Because this is a living document, you should also add open questions you are in the progress of answering to this section.
Visualize the solution: No one wants to read a wall of text, so really use this section to get visual! Partner with an architect to draw out how information flows between systems and capture the results here. Feel free to add a picture of a whiteboard or screenshot of whatever drawing tool you use! Once you have a technical view of the solution, step into the user's shoes and map out how they will experience the solution.
Measuring success: Define what success looks like focusing on the outcome you will deliver for the business. The more specific and measurable the better but that will vary from project to project. If you're struggling to define success, pause this session and try running the Goals, Signals, Measures play before you move on to the next step.
Outline the project's impacts in a table. Which systems and teams will be affected by your project? Which systems and teams will need to make changes for you to deliver your project? At the end of this step, you should have a list of systems and teams touched by your project, any dependencies you have on other teams, and and the relative significance of each impact.
Ready to go
(If you have time at the end of the "Work through the solution" section you can tackle the "Ready to go" section too. If not, schedule an additional 30 minutes or assign someone to make a first draft and then share with your team for review.)
Now that you have a sense of your solution, how it will affect other teams and the value you're delivering to customers, set aside some time to prioritize this project and its benefits against other possible projects your organization/team is pursuing. You might decide at this point to pursue the project or park it for later if your plate is too full. Remember you are trying to deliver as much value to your customers as possible!
Once you've decided you want to move forward with your project, you need to prepare to build it This section will prepare you to kick off your project with your best foot forward. Continue to get feedback from your stakeholders and other teams as you get more specific to ensure everyone is on board with how you are approaching the project and how long it will take.
Be sure to run a full Health Monitor session or checkpoint with your team to see if you're improving.
Break down your project into smaller deliverables that demonstrate progress. As much as possible, make your milestones focused on delivering value to your stakeholders or customers rather than focusing on only delivering technical or backend milestones.
Now that you have your solution outlined from the previous step, who needs to build which parts? Be specific about which people will be involved and what other commitments may hinder their progress on this project. (Don't be afraid to run the new n' improved Roles and Responsibilities play to figure this all out collaboratively!)
Easy. Just run the IT Project Kick-off play!
Want even more Playbook?
Drop your email below to be notified when we add new Health Monitors and plays.
Drop a question or comment on the Atlassian Community site.