I heard a quote today
Simple is good as long as you get it right
The context was a discussion about allocating budget across Control Accounts and Work Packages in an Integrated Master Schedule. This approach to project management resource loads tasks, assigns budget to control accounts, reports progress to plan as a percentage complete against a 0%/100% deliverable.
This may sound complex in some domains but its all pretty simple with the right tools, training and skills.
What is NOT simple - in this discussion at least - is how to allocate the budget across a collection of teams, internal divisions, and deliverables. This is an ongoing almost never ending process, since these are fixed price plus fee type contracts, getting all the numbers lined up is critical to the performance of the job.
When someone comes along and says do the simplest thing what they completely fail to recognize is that simple needs a unit of measure. What is simple for one is complex for another.
What is simple in the small, may be complex in the large - individual spread sheets to keep track of budget and performance. A single person can do this on her desktop. Scale this to 12 subcontractors, 200 people and 3 continents.
What is simple in large, may be complex in the small - SAP used to keep track of budget and performance. A single screen to show budget and performance at the corporate level, requires systems administrators, highly skills cost analyst, an online time and labor system, electronic invoicing, and a baselined and frozen plan.
Both context and domain are needed before simple has any meaning in practice. So the next time you hear some agile pundant say keep it simple or you're not going to need it ask a few more questions about what simple means and what are the consequences of keeping it simple over the life of the program or the firm?
