In my experience, corporate projects are always needed yesterday. Timelines are unreasonably tight, and budgets are too small to accomplish the goal. But, I'm going to explain why that's actually a good thing, and how to take advantage of it.

The best projects begin as Minimum Viable Products (MVP). When designing the first version of any product you should strip away anything that isn't absolutely critical. Be ruthless in this step. If removing the feature doesn't break the app, then remove it.

The smallest app is the fastest app to build. It may not be pretty, and there will be plenty of features to add, but whiz-bang features rarely increase revenue. A slick user interface can come later. An MVP delivers value quickly. Over time you can increment the product to improve on it.

A great example of this is Apple. Almost every product they sell gets an update each year. Take the first iPhone, for example. Steve Jobs touted it as a mobile phone, an iPod, and an internet communications device. Today it is so much more. And while it did other things, the primary features were phone, music, and email. Version 2 added more features, and version 3 added even more. Today we are up to iPhone 14, an incredible device that still does phone, music, and email really well.

Building a minimum viable product also avoids building features that sound useful but actually are not useful. Some features might sound good when considering the old system but may be less useful in the new app.

Here, the MVP helps us again. After users are comfortable with the new system then gather requirements for version 2. Have the requirements changed? Usually, the answer is yes. Again, what is the MVP for version 2? Build that.

After you have been through several iterations of your product it's worth going back and reviewing the original requirements. What you will likely find is that the app, as designed through original requirements would be very different from the app you built through iteration.

End users are not professional software designers. I am not a car designer. Had I been consulted on the first car it may have looked like a faster horse. Deliver the right solution by iterating with MVPs instead of building the wrong thing at first.

One point of note is the difference between features and capabilities. A capability describes the technical faculty of the product. A feature describes how that faculty is leveraged into the overall application. This distinction is important. When gathering requirements users will often describe features, it is our job to tease out the required capability from that description.

I once had a requirement to flash the screen red when an SLA breach was approaching. The user described a capability - notify me before an SLA breach - but they explained it as a feature. I did implement a notification but I didn't make the screen flash.

When running a project with a tight timeline and small budget, use those constraints to your advantage. Pare the project down to its minimum viable components. Build that MVP quickly then begin to iterate. You'll deliver incredible value to the organization and will likely do so on time and on budget.