Recently, Jeff Stanger wrote a post on vetting a web firm after seeing nonprofit site managers bemoan the pain that can be caused by a bad site build.
While hiring a good web development firm is crucial, there are also some steps you can take internally to make for a better build. A “mess of code” can be caused because the developers at the web development firm aren’t experienced enough to write simple code, or they don’t have processes in place to ensure that all code pushed to sites is well-written. It can also be caused by conflicting and ever-changing stakeholder requests that create complications throughout the project.
So while Jeff has provided some great tips on avoiding the former, how can you avoid the latter?
Many of the below are related to stakeholder management within your organization. Your colleagues can be your greatest resource for building a great product, but they can also pose the greatest risk. So how do you get them on board?
My advice, in order of importance:
- Clearly define goals and audiences. Many stakeholders have great ideas for new projects, whether you are rebuilding the site or want to add new functionality. But defining what you are trying to accomplish and who the project is for at the beginning is crucial. By defining goals and audiences, you give yourself guideposts that you can use throughout your decision-making process. It will help you prioritize what is actually necessary and what is a nice-to-have. It will also help you vet requests more easily; if they are not in line with those goals, then it is not the time to build them. Instead, create a backlog list of projects to consider later when new goals arise.
- Designate and empower a Product Manager (PM) for the project. Having one person in charge of the day-to-day management of a large project will make the project run much more smoothly. There are a lot of moving parts that need to be coordinated, a lot of communication, both internal and external, that will need to be managed, and a lot of questions about functionality that must be resolved. This person should have the overall product vision in mind throughout and must have the authority to make decisions and push back on stakeholders, who may have requests that would derail or complicate the project. Depending on the size of the organization and the project, they may also need support from other staff organizing the myriad of details they are dealing with.
- Build internal consensus for the project. Any time you are spending a lot of money to build something that will touch a large number of people at your organization, you will need to do some groundwork first. Make sure that people understand not only what you’re doing, but why and how. Planning a project in a black box, away from stakeholders, is setting yourself up for failure. First, you are not taking advantage of the smart people you work with, and you are not taking their needs into account. Second, you will create resentment in your organization, and that resentment will create friction for every other collaborative process you have. You’re also creating the possibility that people simply won’t use your tool, no matter how good, and you will have wasted time, money, and goodwill.
- Plan moments for input. Integral to building internal consensus is planning moments when stakeholders can provide input. Doing so helps in three main ways. One, by planning these moments, you are communicating to stakeholders that their input is important enough to be included in the overall project plan and scheduled well in advance. You are setting and managing their expectations early in the project. Two, you really do need their input. As mentioned above, they may have wonderful ideas or use cases you hadn’t thought about. If you are building tools that will impact them, you need to take into account what they have to say about designs and functionality. Three, you are controlling when they provide that feedback. Feedback is great, but getting a technical requirement six months into a project build or getting design feedback after you have already finalized the design leads to missed budgets and timelines, and can mean overly-complicated or duplicative code as developers work quickly to address these unaccounted-for requests.
- Plan to measure feature use. Work isn’t done when a product is launched. You will inevitably build functionality or templates that content creators don’t use or don’t resonate with users. By planning for how you will measure that use, whether by making basic information on widget use available to site managers, including reporting processes within analytics that can show you template use, or setting up analytics to measure engagement (something that absolutely should be done), you are setting yourself up well to deal with technical debt in the future. If a feature doesn’t work for your audiences, kill it and get rid of that code from your codebase. If content creators aren’t using a template you built, consolidate that template with another, and again, get rid of that code from your codebase. Managing technical debt is an ongoing process, but by thinking about what you need to know to do so when you first build a product, you’ll make it easier on development teams and product managers in the future.
Managing large projects well can be difficult, but by following the above and with the support of a good web vendor, you can manage it. Building a great and successful product is a team effort!
Be sure to check out the first part of this series – Selecting a Web Partner and Managing for Quality: Five Things, Plus Five More Things by Jeff Stanger – to learn more about how to start tackling your next web project.