When you start a project the first task is to know the who (stakeholders) and the why (reason to be).
1. The who: before you kick off the project, you have to map out the “stakeholders”, to know who is in your project community, to get them on your radar, and start building relationships before you need them.
With your team, get together and brainstorm everyone you think you are going to need to interact with before your project can go live.
Once you have got all the stakeholders, talk about each group and see whether you can start assigning contact names and what they really want, then come up with a plan to engage with these groups.
Once you know your “stakeholders”, then:
- Communicate the goals, vision and context of the project to the team so they can make decisions while executing
- Provide to stakeholders all the information they need to make that ok/no-ok decision on whether or not to proceed with the project
2. The why: the best approach is to ask directly, so schedule start-up meetings, call in anyone directly involved and who can materially contribute to the effective execution of the project, e.g. customers/users, stakeholders, team members, developers, designers, testers, analysts.
Typical start-up meetings can take from a couple of days to about two weeks to complete. It’s good for about six months of project planning and should be revised anytime there is a major change in direction of the project.
The start-up meeting will help to complete this:
- Why you are here: a quick reminder about why we are here, who our customers/users are, and why we decided to do this project in the first place.
- Twitter pitch: how you can describe the project in 140 characters
- Design a product vision: would we buy it?
- Create a NOT list: be clear and show what the project is not about or not doing
- Describe the solution: draw the high level blueprints of the technical architecture to make sure everyone is thinking of the same thing
- Ask about any risks or fears, talk about them, and define what you can do to avoid them
- Set a deadline or lead time to market of this project
- Show what is it going to take, time, money and team required
Before any project team can be really successful, they need to understand the why first rather than what they are building. When they understand the why, teams can do the following:
- Make better decisions
- Do a better job
- Be innovative and come up with better solutions
You need to clearly, and forcefully, explain to your customers what it is going to take to make this project a success. Their involvement, commitment, and engagement are required. Without an engaged customer, your project is in trouble before it even begins.
Read the full series of articles about Agile Methodology: The Basics, Who and Why, How to Deliver, User Stories, Estimation and Planning.
Read more: Jonathan Rasmusson. “The Agile Samurai: How Agile Masters Deliver Great Software (Pragmatic Programmers)” Pragmatic Bookshelf
Carlose Lopez 
Pingback: Agile Methodology Planning | Carlose Lopez | Blog
Pingback: Agile Methodology Estimation | Carlose Lopez | Blog
Pingback: Agile Methodology User Stories | Carlose Lopez | Blog
Pingback: Agile Methodology How to Deliver | Carlose Lopez | Blog
Pingback: Agile Methodology The Basics | Carlose Lopez | Blog