In 20 years of web development every project I’ve participated in has seen its scope change. I love talking with a new client who has everything meticulously mapped in a Gantt chart and it’s adorable when they think it’ll stay that way.
Let’s assume, for all our sakes, that your project is the same. Since we know scope will change, let’s talk about how we should go about doing it.
Before we talk about any of this, here are the three things I consider intrinsic to any web development project: Scope, Budget, and Time
This one’s easy. It’s point A and B. It’s when you start and how long it takes before you’re finished with either a checkpoint or the task at large.
Once again, pretty straightforward. This is the amount of paid man-hours you expect to invest in a project.
Here’s the tricky one. Scope is how ‘large’ a project is. But depending on the project, size can mean anything. How large a database is expected to be, how many features you’re including, even what server you’ll need based on expected traffic. When PXP picks up a new web development project I pay close attention to how many features and how complex they are when determining priority and scale.
Despite how important they are, they can easily be forgotten in the face of more exciting aspects like the vision of your budding startup or fostering new partnerships with some of the razzle dazzle.
You cannot escape the connection these three have with each other. If you increase or decrease your allotted time -- budget and scope changes by necessity. And if you insist on changing one while keeping the others static, you’re going to create unrealistic expectations that will lead to conflict and risk the total collapse of a project.
So why change any of these aspects once you’ve established them? You had that Gantt chart didn’t you?
Sometimes your scope has to change. Turns out you don’t have enough time or that your budget is smaller than expected. High-end, flowery features have to take a pass when it comes to getting your project up efficiently. It can be disappointing but you’re willing to pump the brakes to keep your startup going. It’s a sacrifice in hopes of including those features later on.
Other times you want to swing for the fences. You’re looking at your project and think that extra boost is going to put your project head and shoulders above the other competitors. It’s going to take more time and money, but you’re willing to floor the gas to take the lead with your startup.
These are both realistic reasons. Whether you’ve got to take a step back in scope or dive forward, you’re not escaping time or budget. If you attempt either of these situations while maintaining budget and time, you’re about to create a dreadline.
As a startup, it’s important to realize that the investment of time and money is integral to the scope of your project. It’s not a bad thing to change scope for either of those factors. If you find yourself wanting to change scope but budget and time won’t allow for it I have only one suggestion:
Get it out there. You won’t serve the project by spinning your wheels with that tug-of-war. And once it’s launched you can iterate on it again -- this time with a new budget and timeline that will help you chase the scope you’re aiming for.
We will send you the report from our audit findings for free