My Google search for the origins of this expression were surprisingly sparse, however after about twenty minutes and a large mug of coffee, I found the definition on urbandictionary.com. “Origin: U.S. rural. Refers to anything filled to or beyond capacity.” That being said, this expression is well known to most of us. Nowadays, it means trying do too much with the resources we have at hand in the time given. This is especially true when trying to commit to Plan of Record. 

This question inevitably comes up in almost every program. There is always too much work to do in the time allocated. Everyone wants something and they want it yesterday. Product Management has feature requests. Inbound marketing has customer requests. Global Services has RAS functional requests. Engineering has quality requests. The question for the program manager is how this “request-a-pa-looza” merry-go-round does not keep the release in a perpetual cycle of bargaining-negotiation. Even after a Plan of Record is established, how to avoid a constant stream of Plan of Record Change Requests.  

Project Management Triangle

Wikipedia defined the “Project Management Triangle” as the following.

In this model, the cost is meant to represent resources. Typically in most companies, this is the most fixed of the legs of the stool. You can only change this leg with great difficulty and it usually takes a very long time to hire well qualified people. 

Assuming that this leg is fixed, that leaves the remaining two legs. 

1. Scope
2. Schedule or Time to Market. 

These two legs are always at odds with one another. They are a venerable Scylla and Charybdis from Homer’s The Odyssey. In the story, Odysseus successfully sails his ship past Scylla and Charybdis, but Scylla manages to catch six of his men, devouring them alive. Navigate your program too close to either of these can be just as disastrous. Product Management and Engineering know this well. Sail too close to scope and your competitors will gobble up your market share making penetration very difficult when you are finally ready to go to market. Sail too close to schedule and you run the risk of coming to market with a very incomplete product. This action could severely damage your corporate reputation. 

Program managers are stuck in the middle. They are looking for ways to efficiently move the program out of the planning phase and into the development phase. This phase usually takes too long. 

The first set of negotiations is  between Product Management, Product Marketing, Global Services and Engineering. The goal should be a ranked list of features engineering can review. 

The second set of negotiations is what can Engineering commit to in the designated amount of time allotted. 

And typically this goat rodeo goes around and around several times as new features come in and groups assess the features which did not make the cut and immediately want to renegotiate. 

The result? An inefficient planning phase where time is wasted in trying to wring out every last ounce of engineering effort and still hold close to the target date. 

Additionally, even though you have an agreed upon POR, the program is under a constant assault of new customer features which come in during development, new use cases, reaction to real time competitive analysis, etc. 

Agile Method

Agile allows us a solution by allowing the team to only commit to the major theme of the release. All other features are malleable depending upon the decision of the product managers/solution architects. The issue here is that there is always a desire to squeeze more key features in. While time to market may be improved with the much smaller focus/greater frequency of an Agile process, there are still the huge product backlog that need to be seen to. The tendency is to start drifting away from orthodox Agile processes to something of a blended process.  This slippery slope can get more and more features committed and start looking more like a classic waterfall over time. 

3Lbs in a 5Lb Bag Method

Another approach for a waterfall methodology may be to not fill the release to capacity during the planning phase. While the notion probably makes the executives uneasy, it will allow space for new features which inevitability crop up during a release. Given the smaller scope and longer duration of time, engineering can in theory accommodate the requests easier with less disruption and decommitting half-coded features. 

Train Station Method

Another approach would be a rigid application of the train model. Basically, the train gets loaded up at the beginning of the release and when it leaves the station, all late comers get on the next train. While this would impact the change to the plan of record after the commit, it may lead to a longer planning cycle as everyone knows the implications of not being in the release and a negative customer impact if a key customer needs a feature and is unwilling to wait for the next release. 

Conclusion ?

After talking with many of my colleagues and friends, the general consensus is that there is no perfect approach to this issue. Personally, I am for Agile but only if the company can err on the side of  committing to it. Whatever path you take, a healthy dose of realism and understanding of all the vertices of the project manager triangle and how they impact the final deliverable is needed. Everyone may not walk away happy but they will know that the best product was delivered under the given constraints.