Until you answer these questions, you can never hope to answer the question of whether you have a chance at accomplishing your project’s goals. If you can’t adequately address and answer any of these questions, you should immediately stop your efforts. There is no reason to continue if you don’t why you are undertaking your project, what features have to be delivered, when you need the features, how and by whom will delivery be made, there is no rational business reason to undertake the project. Once you answer these questions, only then can you address how much your project is going to cost to deliver and thus determine whether a positive return on investment is feasible. Again, if the answer is in the negative, there is no reason to continue with the project as specified.
It is important to note that this article isn’t a re-hash of the 5 W’s and 1 H questions to gathering information. There are two important distinctions. First, I don’t regard the question of Where to be all that important. In a stretch, I suppose I could have asked where in the business will the application be deployed. As I see it, that question is essentially answered when you ask What it is you are trying to build. Second, the 5W’s and 1H looks back at history. What happened, why did it happen, how did it happen, etc. Here, I take a forward looking approach – which is what you need before you embark on a software project or any kind of project for that matter.
Why?
Presumably, you’re entertaining a project to address some business need. It seems like a basic, common sense question to ask. And yet too often, too many businesses embark on a project without asking why they are embarking on such a project in the first place. Implied in this question are important elements like business requirements, which in the Agile World form the basis of User Stories (Product Backlog Items in Scrum).
What?
After you have answered why, you can begin to chart out what the delivered solution will look like. This is not about the technology stack. It is much too early to think about that question. Rather, this is about your feature set that is codified by your User Stories that support your business requirements. A good feature is something that does one thing very well. That’s also a hallmark of a good user story; something that describes one thing well as well as acceptance criteria and a definition of done. With your solution decomposed to smaller feature subsets, you can then prioritize their importance and relative effort to deliver each feature.
When?
When will you need these features in order to deliver value? Ideally, you don’t need every feature 100% complete on day 1 in order to deliver the required value. If that is the case, then time is your enemy, but not for the reasons you think. You might think the issue is that the problem is too complicated to get done in your required time frame. That’s not the issue. The real issue is that you got started too late. It’s almost never the case you need everything right away. Instead, and what is more likely, you need some features sooner than other features such that delivery can be incremental. Your task is to prioritize those feature deliveries accordingly.
How?
In answering how the features will be delivered, you begin to confront the technical stack, cloud vs. on-premise, in house custom solution or a third-party solution. If you need something quickly and perhaps you don’t want to invest in support, you may opt for a third-party solution. For some problem domains, like a Customer Relationship Management (CRM) or Enterprise Resource Planning (ERP) Solutions there is almost no reason why you would ever opt for a custom in-house solution. Sometimes how you wish to incur costs will drive part of this decision. For example, if you want a pay as your go model (OpEx), you may elect a cloud-based approach. On the other hand, you may prefer a capitalized cost approach (CapEx) or have some other constraint that makes the cloud not feasible.
Who? (And ultimately cost)
At this point, you know what you need, when you need it, why you need it and how the solution will be built and delivered. . The question is who is going to deliver your project. Are you going to use in-house talent or will you contract with an external vendor? Do you have the necessary talent in house? Required talent level may be fluid depending on when you need your solution. The shorter the time frame, the better your talent level will need to be. If your internal staff doesn’t have the right skill set or the bandwidth, you may need to leverage a third-party vendor to deliver your project. If you find yourself needing to hire a vendor, it’s absolutely critical you have requirements clearly defined. In the event you have poorly defined requirements, you run the risk of choosing an unqualified vendor. You also run the risk of significant cost overruns. In these cases, it’s helpful to consult the 3 primary constraints of scope, time and cost. Together, these three constraints define quality.
Every project is subject to constraints:
- Cost: Every project has a finite budget.
- Scope: Only projects with clearly defined requirements can be well managed.
- Time: Delivery is the most important feature – dates matter.
Cost, scope and time can also be expressed as the choices of good, cheap and fast. It goes like this:
- If you want it cheap and good, delivery will not be fast.
- If you want it good and fast, delivery will not be cheap.
- If you want it fast and cheap, delivery will not be good.
Accordingly, if you are faced with a situation that requires your project or a particular feature to be good, cheap and fast, you first need to look at the scope and decide if it is possible. If not, you need to endeavor to reduce the scope until it is possible. If that can’t happen, then either the time (fast) or cost (cheap) constraint has to give. In no case can the quality (good) constraint be compromised because if something isn’t good, it isn’t useable and therefore, cannot deliver value. Something that cannot deliver value isn’t worthy of being built in the first place.
In summary:
- To manage quality, you must manage the constraints of cost, scope and time.
- To adequately address cost, scope and time, you must address the questions of why you are embarking on your project, what business problem your project will address, when do you need your project delivered, how your project will be delivered and who will deliver your project.
