[Editor’s Note: we use a variation of the project management triangle]
Know the Trade-offs from the Beginning
A decision maker with a vision must work with their team to turn that vision into action items that can be implemented. In a world of constraints, how a project is setup is extremely important before getting started determining what is to be built when.
Before we execute on a project, we follow the practice of providing the stakeholder a choice on how the project is prioritized: price, quality, or time. They must choose two out of three. This serves two important purposes. The first is that we educate from the beginning, or weed out, people who would have unrealistic expectations of how custom software projects perform. The second is that we align all participants of the project early to prevent many misunderstandings and delivery of milestones that fall below expectations.
We define these choices as follows:
- Price. How important is it that the project stays within a budget or agreed price. In the PMT this is known as Cost.
- Quality. How important is it that the project has polish. In many projects, 80% of the vision can be done with 20% of the time. In the PMT this is often called Scope.
- Time. How important is it that the project be accomplished by a certain time.
Now, given a choice of two, we are left with three permutations. Here’s how each one would work.
Price + Quality
P + Q is for polished deliverables on a budget.
In these projects the work is done at a measured pace and decision makers are expected to be active participants required to answer important questions at certain milestones. They will often be presented with options. Time will be taken to think about the solutions. There would be no firm deadline for delivery, only educated estimates. These projects could even have gaps in work as the team awaits the right resources to become available. We find these projects are most common and most recommended. We also find them to be the least stressful for all parties. A well defined roadmap with realistic milestones can often work with P + Q.
Quality + Time
Q + T is where there is an urgent need for a solution and it has to be polished, or meet specific, inflexible, requirements.
When there is a hard deadline the participants must work harder and faster to identify and mitigate project risks. Escalation fees and extra time should be expected because work must be done to accommodate multiple paths before one can be chosen. There is not much time to sit back and think. The decision makers and participants will need to be available to discuss and make decisions ad hoc. It is not uncommon for these types of projects to cost many multiples more than a P + Q project with the same deliverable. Having people with tacit knowledge of the impacted systems would help mitigate some of the cost. We notice these projects tend to arise when a decision maker is presented with an unexpected opportunity.
Time + Price
T + P is where there is an urgent need with a fixed budget.
Everyone needs to be pragmatic here. Risk is mitigated by reducing scope. The requirements should be adjusted to fit what already exists or off-the-shelf solutions. Ad hoc meetings will be necessary. At BLT, these projects are the most rare and usually require a previous working relationship in order for them to be entertained.
Only projects where we believe there is a high likelihood of meeting or exceeding expectations can move forward. We are a reputation based organization and cannot afford to undertake projects where we can’t succeed. We find that P + Q + T helps both parties get on the same page or move on in an efficient manner.
Change Happens
During execution of a project priorities can change for many reason. It is important that this concept is revisited from time-to-time to make sure someone is not trying to do, or expect, too much. We plan to detail out expectations for each pair during all parts of the software development lifecycle and where we have seen projects drift off course.
Stay tuned!
