How to plan a Drupal Project
When a client comes to you with an amazing idea for the project that is going to change EVERYTHING in a market, enthusiasm for getting down and building before thinking through how that goal might be achieved is very common. You may get a "plan" on the back of napkin. There are a few approaches that you can take to reach the client's ultimate goal.
- Take the project in a pure agile fashion, agree on the price for sprints, prioritize features, and then plan for each sprint iterating on each sprint until the project is finished or the budget is exhausted. For some clients, those who you can TELL don't know what they want and have a limited budget, this approach is a sure path to an unhappy client.
- As part of the entire budget, plan the project up front (as much as you can - there are lots of unknowns in any software build), and then move into development. Psychologically, this seems to cause some level of anxiety. There is the perception that development budget is being burned and there is nothing to show for the effort.
- You can start with a definitions contract to begin with. Up front, separate from the build budget, define your data model, create your wireframes, and think through the major work flows. The deliverable for this contract would be a definitions document that the client can take to any other development shop if they really desired.
5 Rings has chosen to take the third route whenever feasible. What we've found is once the client has gained trust and has a comfortable relationship with you, they will not go to another vendor even if the final phase of the definition is to reduce scope on the overall project to develop a Minimum Viable Product (MVP).
But Matthew! You preach Agile! Are you changing your tune? On the contrary, the definition does not prevent you from...
- Making iterative changes to the plan as they make sense
- Operating in defined sprints
- Writing user stories to support the use cases
- Having daily scrum meetings
- Convening retrospectives
- Demonstrating working software to the client at the end of each sprint
What it does do is set expectations with the client. You get far fewer instances of "This is not what I imagined" and gives you an amazing opportunity to train the client on what Drupal really is and the power of contributed code. It makes making compromises much easier as you get into "tough spots" because you have already developed a strong rapport and style of communication. Builds go far more smoothly because you have a plan in place that you can follow.
How Do You Convince a Client To Engage In a Definitions Contract?
It is surprisingly easy. Sometimes they will be coming to you to solve a specific problem. In other instances they will be looking for a site that can help them sell a product or service. In other cases, they will want the remediation of an existing project. If you start the conversations with how you make a plan to solve for the challenges, you are setting the right tone. When identifying the major pain points, you can fairly quickly shift the conversation to a low risk proposition by suggesting a definition phase where you figure out exactly what the project is.