Web Application Project Origin
You want to build a web application that solves a business problem. You’ve got some ideas in your head about how it could work. You want to translate these ideas into working software.
The first step to doing this is to be explicit about your situation. You need to be clear about why you’re building this software, what you want to build, and what success looks like for this project.
Once you’ve answered those questions, you’ll have the information you need to make a plan to actually implement the project. You’ll be able to start thinking about the expertise you need, the scope of your project and the sort of budget you should be considering.
Why are you here?
- Who exactly is going to use your software?
- What problem are you solving for them?
- How have they been solving that problem until now?
- What is bad about the way they’re solving it now?
- Who are you and why are you building this software?
- All software projects are investments, so what are the investors in this project hoping to get out of it?
- Who are the key people motivated to get this project built?
- Why do they want it built?
What are you doing?
- How are you going to solve your users’ problem?
- What will the software allow your users to do?
- How will your solution be better than what users are already doing?
- How much can you invest in building the solution?
- In a few sentences, can you describe how a user will interact with your proposed solution?
What does success look like?
- If your project has an external time constraint, when does it have to go live for it to be a success?
- Are there any key metrics that can be used to measure it’s success?
- What features must be shipped for it to successfully to solve the targeted problems?
- What goals need to be achieved for the project to be a success for investors?
- How will you confirm that those features in fact solve the targeted problems?
- What doesn’t have to be completed for the project to be considered a success?
Writing a project charter
These questions are there to get you thinking in explicit terms about why you’re working on this project, what exactly you’re building and how you’ll know when you’ve succeeded. Working through these questions will help you gain clarity and direction.
There are a lot of benefits to getting your answers to these questions on paper. A project charter captures this information.
Going through the motions of writing a project charter has a number of benefits:
- With a central, high-level document specifying the project’s purpose, the project becomes easier to share, discuss and refine.
- New team members can gain an understanding of the high-level context and goals of the project at a glance.
- When there are disputes about the direction of the project, the team or other stakeholders can consult the charter to help make decisions.
The project charter should include, at the minimum:
- A code name. Software projects typically go through many name changes before a final name is settled on. A code name helps you easily refer to the project without worrying about the final name.
- An answer to the question of why you’re building this software.
- A description of what you’re building.
- A definitive picture of what success looks like.
- Any additional information, including a project timeline, details of key stakeholders, links to further reading and anything else that someone new to the project would find useful.
The charter should be short enough that your team members will actually read it. It needs to be kept up to date so that it’s still useful for the team and anyone that finds themselves needing information on your project. If it gets too long or otherwise stops being useful, it should be edited down or deleted outright.
Once you’ve got this information in one place, the next step is to start to plan how you’re going to get closer to the project’s success criteria. That means thinking in detail about the desired software you want to build, about the team you’re going to need to assemble to build it, and the steps you’re going to take to minimise project risk.
- Najaf Ali