If you are in charge of overseeing development of a web software application, you probably already know the importance of the roadmap, i.e., the short-term and long-terms goals and planned features of the product.
However, if you’re working with an external web development company, it can be difficult to conceive and implement the big-picture roadmap. Some of these difficulties are just part of the challenge of working with any external party. Some difficulties are specific to coding projects.
In this guide, one of a series, we’ll look at some ways you can get more clear about your product’s web project management plan (or product roadmap) when working with external teams, and also what you can do to make your life as a manager easier.
Factors in A Product Roadmap
As you know, all projects are different and there are so many project-specific factors. Here are some of the major factors that can influence the specifics of a product’s roadmap:
- Workflow differences. Some development is done in an Agile, continuous development style; other dev projects are done in a Waterfall, one-chunk-at-a-time style.
- Budget. Obviously some projects are high-budget with money being no object; others are small.
- Dev/maintenance team relationship. Related to budget, some third-party suppliers will be very hands-on and be involved in all facets of the app development and strategy; some suppliers will just be focused on doing assigned, one-off tasks.
- Priorities. For some products, small and frequent updates are necessary. For other products, there must be large rollouts of features all at one time.
Considering all the factors that could be present, it’s admittedly difficult to give one-size-fits-all advice on optimising an app’s roadmap. But we’ll try. Probably the first thing you should think about is:
Do You Have A Strong Roadmap In Place?
If you don’t have a strong roadmap (or any roadmap), that’s a problem. A roadmap for software development doesn’t need to be super-specific schedule-wise, but it should be fairly detailed in terms of overall goals and features. Ideally a roadmap will include the following information:
- The overall mission of the application/product
- The problems the app and app features are intended to solve
- Who the shareholders are
- Short-term and long-term features to be added
- A system for prioritizing work to be done on the product
Some projects will have a strong roadmap in place, with very clear, company-wide understanding and communication on all facets of a product plan. On other projects, the roadmap may be a bit vague or even non-existent. Or there may be a well-communicated roadmap but the long-term implementation has fallen by the wayside a bit.
Try to understand where your company falls in this spectrum.
Challenges With Implementing Roadmaps
There are two major (basically opposite) challenges that come up when trying to implement existing roadmaps:
- Management is focused on getting to the big, long-term goals so much that they’re not polishing and optimizing the existing code as they go. (This can especially be a concern for the projects that are done Waterfall-style.)
- The team is focused so much on “putting out fires” and handling bugs that they are letting long-term, big-picture goals slip.
It can be easy to fall into either of these ruts at either extreme. Optimal product management can be a fine balance of many complex inputs and outputs. The more clearly you understand the roadmap and understand what are the most important goals, the more easily you can find that balance.
Define The Relationship Between You and Your PHP Consultant
If you are reading this article, there’s a good chance your company’s roadmap was in place when you came on-board the project and you are trying to reach an understanding of it.
You may be in the position of overseeing an external PHP team that has been working on the project for a while. If this is true, it can be a challenge trying to understand how that team is working on things and what the big picture is.
One of the major factors in how a product plan is being implemented is your company’s relationship with your devlopers. There are all sorts of relationships possible, anything from a bare-bones relationship where you just assign them tasks/features to implement with little feedback from them, to a very hands-on process where your supplier is involved with strategy, feature brainstorming, and the like.
What relationship your company has with your supplier is based on such things as the complexity of your app and your budget. One of the first steps in optimizing your product’s roadmap is to get clear on the relationship your company has to your supplier and if that relationship makes sense for your goals and roadmap.
At our company, Siftware, we mainly focus on jobs where we have a more hands-on role in the app development. For many of our clients, we are involved in the brainstorming and give feedback on feature ideas and how those features would best be implemented. If our clients tell us “make such-and-such happen”, we consider it part of our responsibility to point out any possible flaws in that approach and possible alternative ways to approach a solution.
For example, if a client tells us, “We absolutely need 99.999% uptime,” we need to explain to them the cost of implementing that and help them understand if such a decision makes sense considering other aspects of their business.
The practical takeaway from this is that a good shop will usually give you some “pushback” on your ideas. It would be abnormal to receive no pushback whatsoever, simply because most ideas and feature implementations are complex.
This is not to say that there isn’t a place for shops that just do the assigned work with no feedback. There is a place for that, especially for simpler jobs and jobs with small budgets. Sometimes that’s all you need. But the point is that it’s valuable to understand your relationship with your supplier and how it might impact your long-term goals.
Set Up Clear Communication Lines
A roadmap for app development is often a vague thing. So many things are subject to change; this means that hard schedules usually do not work out.
But there’s still value on getting clear on how your PHP developer creates schedules and how they assign priorities.
How do they understand the big picture and the roadmap? Maybe they don’t, and it’s not a good idea to assume that they do. The better your lines of communication with them, the fewer surprises there will be.
Some methods of improving your lines of communication with your supplier include:
Ask questions. Asking questions about how the team is approaching their work will allow you to see if they are adhering to your idea of the roadmap. And you’ll learn a lot about the process to boot. Ask them questions like:
- How did you decide on the priority of the task/feature you’re currently working on?
- What other things do you plan on working on first or after?
- What potential obstacles or challenges do you foresee and why?
Hold regular (perhaps weekly) project-status meetings. These video-conference meetings can include some screen-sharing of the app. These meetings will allow you to get a sense of how the team is adhering to the roadmap and see how the features are progressing.
These regular meetings also help prevent misunderstandings and time-wasting tangents (which can be very expensive if noticed much later in the process).
Make sure they know what’s next. Going hand-in-hand with you needing to know how your supplier is working, ideally you should be keeping your supplier in the loop about what is coming next and what is expected of them. If the team has a clear idea of what’s expected of them, they can make better plans and anticipate problems.
Understanding The Complete Process
This might be a bit obvious, but part of being an effective product manager is about understanding the time it takes to complete tasks and the potential challenges that can prolong completion.
The more that your lines of communications to your supplier are clear and the better you understand the process, the easier your job is and the smoother the app development process goes.
A few examples of things to keep in mind that are sometimes overlooked by managers of third-party teams:
- Factor in deployment time. Even once the code for the app or feature is complete, it will take some time to deploy.
- Factor in bug fixing. Bugs will happen, no matter what. The more complex a project it is, the more bugs there will be.
- Factor in auxiliary projects. Are there other related projects that go hand-in-hand with the code? API documentation and end-user documentation are some examples of related projects that are sometimes overlooked until the last minute.
Some Additional Resources
If you’re not very familiar with the Roadmap concept, this is a good article that talks about some ways that planning for software and app projects is different than for other products. Also, there are some additional helpful articles linked in that article.
Hopefully this article has given you some ideas on how to get clear on how your external team is implementing your app’s roadmap and how you might improve that process.
And if You Need Help…
Who’s “us”? We’re Siftware, a firm run by me, Darren Beale. I’m a long-time PHP consultant turned manager and my team includes other respected PHP developers. Over the years, we’ve worked with a diverse client list, overseeing their PHP development and providing ongoing support.
Our service offering is laser focused and we only work with owners or managers of existing PHP applications. If you would like to find out how we can help you please don’t hesitate to book a free consultation.
Many companies have web applications that require ongoing tweaking and maintenance. A common solution is to hire a third-party supplier to…Read more
If your company has a software development team that maintains your web application code, whether internal or external, you want to…Read more
If you have a web application that is critical to your business, it’s important to understand how to mitigate the risks…Read more
10 Tools to Reduce Outsourced Web Development Risk and Expense