Project inception

Editor's Notes

• #4: - At the start of any new project, people usually have wildly different ideas about what success looks like. - This can be deadly for projects because although we will all be using the same words and phrases to describe what we want, it’s only when we start delivering that we realize we’re all thinking completely different things. - And the problem isn’t that we aren’t all aligned at the start (that’s nat- ural). It’s that we start our projects before everyone is on board. - The assumption of consensus where none exists is what kills most projects.
• #5: What we need is something that does the following: • Communicates the goals, vision, and context of the project to the team and product owner so they can make intelligent decisions while executing • Gives the stakeholders the information they need to help them make that go/no-go decision on whether or not to proceed with the project
• #6: Developed at Thoughtworks to deal with issues Agile methods like Extreme Programming (XP) and Scrum were silent on—project chartering and inception - Light-weight alternative It’s a collection of ten tough questions and exercises you’d be crazy not to do and ask before starting any project. A fast, lightweight way to distill a project to its very core and communicate that shared understanding to the greater team and community.
• #10: - Why are we here? - What’s the commander’s intent? -> should be able to answer this in one sentence - Before any project team can be really successful, they need to under- stand the why behind what they are building. When they understand the why, teams can: • Make better, more informed decisions • Do a better job of balancing the conflicting forces and trade-offs • Come up with better, more innovative solutions because they are empowered to think for themselves - It’s all about discovering your commander’s intent and going and seeing for yourself. - It’s that statement, or guiding light, you can turn to in the 11th hour, in the thick of the battle, that helps you decide whether to press the attack or hold your ground.
• #11: - It’s all about discovering your commander’s intent and going and seeing for yourself. - It’s that statement, or guiding light, you can turn to in the 11th hour, in the thick of the battle, that helps you decide whether to press the attack or hold your ground.
• #12: - A good elevator pitch: 1. It brings clarity: Instead of trying to be all things to all people, the elevator pitch forces teams to answer tough questions about what the product is and who it’s for. 2. It forces teams to think about the customer: By bringing focus into what the product does and why, teams gain valuable insight into what’s compelling about the product and why their customers are buying it in the first place. 3. It gets to the point: Like a laser, the elevator pitch cuts through a lot of cruft and gets to the heart of what the project is about. This clarity helps set priorities and greatly increases the signal-to-noise ratio of what really matters. - Let’s now look at a template to help form your pitch -> NEXT
• #13: The one I like comes from Geoffrey Moore’s book Crossing the Chasm • For [target customer]—Explains who the project is for or who would benefit from its usage. • who [statement of need or opportunity]—Expands on the problem or need the customer has to solve. • the [product name]—Gives life to our project by giving it a name. Names are important because they communicate intent. • is a [product category]—Explains what this service or product actually is or does. • that [key benefit, compelling reason to buy]—Explains why our customer would want to buy this product in the first place. • Unlike [primary competitive alternative]—Covers why we wouldn’t already use what’s out there. • our product [statement of primary differentiation]—Differentiate and explains how our service is different or better than the com- peting alternatives. This is the big one. It is where we are really justifying the expenditure of money on our project.
• #14: How to make it: - You can print the template and have everyone take a stab at filling it out themselves before bringing everyone together. - Or, if you want to save a few trees, you can just beam the template up onto the screen and tackle filling it out as a group, going through each element of the template one section at a time.
• #15: - Amazon - call it “working backwards” (almost TDD for product development) There is an approach called "working backwards" that is widely used at Amazon. We try to work backwards from the customer, rather than starting with an idea for a product and trying to bolt customers onto it. While working backwards can be applied to any specific product decision, using this approach is especially important when developing new products or features. - For new initiatives a product manager typically starts by writing an internal press release announcing the finished product. The target audience for the press release is the new/updated product's customers, which can be retail customers or internal users of a tool or technology. Internal press releases are centered around the customer problem, how current solutions (internal or external) fail, and how the new product will blow away existing solutions. - If the benefits listed don't sound very interesting or exciting to customers, then perhaps they're not (and shouldn't be built). Instead, the product manager should keep iterating on the press release until they've come up with benefits that actually sound like benefits. Iterating on a press release is a lot less expensive than iterating on the product itself (and quicker!).
• #16: If the press release is more than a page and a half, it is probably too long. Keep it simple. 3-4 sentences for most paragraphs. Cut out the fat. Don't make it into a spec. My rule of thumb is that if the press release is hard to write, then the product is probably going to suck. Keep working at it until the outline for each paragraph flows. Oh, and I also like to write press-releases in what I call "Oprah-speak" for mainstream consumer products. Imagine you're sitting on Oprah's couch and have just explained the product to her, and then you listen as she explains it to her audience. That's "Oprah-speak", not "Geek-speak". Once the project moves into development, the press release can be used as a touchstone; a guiding light. things that aren't in the press release (overbuilding), they need to ask themselves why. - QUOTES, TWEETS ABOUT the product
• #17: - The NOT list is a great visual for clearly showing what’s in and out of scope for your project. Basically, you get together with your customer and team and fill in the blanks brainstorming all the high-level features they’d like to see in their software. - As important: Things that “could be in scope but are not” - keeps you focused and avoids having the same discussions over and over again
• #18: - The NOT list is a great visual for clearly showing what’s in and out of scope for your project. Basically, you get together with your customer and team and fill in the blanks brainstorming all the high-level features they’d like to see in their software. - As important: Things that “could be in scope but are not” - keeps you focused and avoids having the same discussions over and over again
• #19: - By meeting your neighbors, you can build relationships up front that will give big dividends down the road. It’s also courteous to say “hi” instead of just running to them when your house is on fire. And most important, it’s essential for building the foundation of every successful project community—trust. - With your team, get together and brainstorm everyone you think you are going to need to interact with before your project can go live. Find contacts within those groups.
• #24: - Asking ourselves what keeps us up and night invites a healthy discus- sion about some of the challenges you and the team might face when you’re delivering and what you can do to prevent them from ever seeing the light of day. - Talking about project risk is one of those things that most people would rather skip when starting projects. No one wants to look like Chicken Little, running around saying the sky is falling. But talking about risk is a great way of letting people know what you need for the success of your project.
• #25: - Get together with your team (including your customer) and brainstorm all the possible risks you could see happening on your project. You are the sword your customer is going to be swinging on this project, so anything that’s going to affect your ability to chop would be good for them to hear. - Then with your great big list, take all your risks and split them into two categories: those worth sweating and those that aren’t. Michael Bloomberg on risk: 1. Write everything down that could possibly go wrong. 2. Think really hard about how to stop those things from happening. 3. Then tear it up.
• #26: - This is about trying to figure out whether we have a one-, three-, or six-month project on our hands. We can’t get much more precise than that at this point in our project, but we still need to give our sponsors some idea of when they can expect their software to be delivered, even if it is only a really rough guess. - But for now, pretend the team has already done the estimates for the project, and here we are just presenting the results.
• #27: - Did you find yourself thinking, “It depends”? - There are no absolute right or wrong answers to these questions. They are intended to show you that there are forces at work on your project and striking the right balance between them takes work. - sliders
• #28: - Budgets and dates tend to be fixed. Scope regularly seems to increase with reckless abandon. And quality is always #1.Yet these forces are often in conflict. Giving in to one means taking something away from the others. If left unbalanced for too long, the force of one can overwhelm a project until it finally breaks and snaps. Something has to give. The question is what? - Quality: NOT bugs -> *ilities - A date may be fixed. But a plan is not. And so, out of the four forces arrayed against him, the agile warrior will fix time, budget, and quality, and flex the project around scope. - Once the forces are named and plain for all to see, the warrior will ask their customers to rank these forces in order of relative importance. No two forces can occupy the same level of ranking (in other words, they can’t all be #1). Not 2 on same
• #30: - There’s nothing more confusing to a team than not knowing who to take their marching orders from. The director of IT wants to prove the latest technology. The VP of strat- egy wants to be first to market. The VP of sales just publicly committed to a new version for the second quarter. - You can’t have multiple stakeholders, all approaching the team with different ideas about where the team should be headed, what the pri- orities are, and what to work on next. Instead, you want to make it very clear up front who’s driving the bus. That doesn’t mean other stakeholders don’t have a say—far from it. We just want the customer to speak to the team in one voice. - By putting this slide up and raising this issue now, you can avoid a lot of confusion and costly rework and realignment later. Even if you think you know who is calling the shots, ask anyway. Not only will this remove any doubt, it will also make it crystal clear to the team and the other stakeholders who the ultimate decider really is.
• #31: - There’s nothing more confusing to a team than not knowing who to take their marching orders from. The director of IT wants to prove the latest technology. The VP of strat- egy wants to be first to market. The VP of sales just publicly committed to a new version for the second quarter. - You can’t have multiple stakeholders, all approaching the team with different ideas about where the team should be headed, what the pri- orities are, and what to work on next. Instead, you want to make it very clear up front who’s driving the bus. That doesn’t mean other stakeholders don’t have a say—far from it. We just want the customer to speak to the team in one voice. - By putting this slide up and raising this issue now, you can avoid a lot of confusion and costly rework and realignment later. Even if you think you know who is calling the shots, ask anyway. Not only will this remove any doubt, it will also make it crystal clear to the team and the other stakeholders who the ultimate decider really is.
• #32: This is a good time to talk about roles and responsibilities and what is going to be expected of everyone when they join this project. One role I usually spend a few extra minutes on is the customer. First, it’s super-important, and second, it’s not really baked into most com- panies’ DNA. Here I like to look the customer in the eye and make sure they understand what they’re signing up for when they choose to join an agile project. Can they commit the time? Are they empowered to make the necessary decisions? Are they willing to direct and steer the development of this project?
• #33: - Visualizing the solution is about getting a read on what we’re going up against technically and making sure everyone is cool with how we are going to build this thing. - You just get together with the technical folks on your team and talk about how you are going to build this thing. You draw architectural diagrams, play what-if scenarios, and generally try to get a feel for how big and how complex this thing is.
• #34: - You are almost there! You’ve got the vision. You’ve got the plan. - Now you just have to figure out what it’s going to take and how much it’s going to cost.