[Second in a series of articles and artwork.]

What am I saying? The easy path is the gravy train of all company bottom lines right? Wrong.

Easy is the devil of the largest failures in history. This is not to be confused with ‘Fail Fast‘ concepts. If project deliverables seem too easy, there is a good chance the original estimator missed something or didn’t consult a Subject Matter Expert in that area of expertise. Sometimes risk is removed from projects by removing the estimated variance of unforeseen complications not researched properly.

One of the early symptoms of a bad project, is the path of activities that appear to be easy. This easiness are built into the estimate and make the final bid lower than the competition. Typically an easy task is clouded by some level of ignorance, bad definitions, bad or misused syntax, extra ordinary time pressures and get-r-done mentality.

How many times, have you heard a team members say something like, “That’s an easy fix. It will take 5 minutes.” Afterwards the team-member goes dark and the easy fix ends up becoming an effort that takes days. Ultimately the project timeline bounces around so much that it affects other team members and the burn rate of the budget increases due to the ripple-effects.

#1 English is Code.

The seeds of loss are often sown in the Statement of Work by people who just don’t know how to write a scoping document or they can’t write at all. English is a marvelous language and has all the nuance of a crafty CSS document. English can nest concepts and it can cascade meaning, architecture and properly add timing metrics as well.

Look for words that that do not scope effort. The easy ones are general words that don’t frame a metric type in the document’Any’, ‘All’ are culprits. Watch for words that don’t frame up their effort over time and which make more effort – “The web project will adhere directly to the most up-to-date browsers.” Sounds great but you are promising that the project will be tested for 1-3 browsers during an extended period of time like 8 month or more? Are we included Canary in that mix of browsers?

#2 Don’t copy a copy

Instead of starting with a fresh copy of a scoping document, someone will suggest, for the sake of speed, to simply edit a past project scope document. The copy will usually have been the first approved document but will lack any additional notes or addendum of change in the project – these might be: Change Orders, Budget reports, Scope Shift, etc. When copies are used of past projects, the updates to be successful were never added back to the document typically.

#3: Look for trap words.

These might be typical verbiage or reserved words. Often one will never hear the term easy. The language that is used is hidden as other terminology. ‘Lift and Shift’, ‘Migrate Content’ are a few well used. Some of the bigger projects will say something like ‘We don’t have to worry about that…. the legacy system will pass the calculated variables to the client.” My favorite and the most deadly is “the client will be doing that task so take that off your estimate.”

#4: Avoid Acronyms

Larger companies will mask some of the easy tasks as clever acronyms – do your homework in that industry to understand what you’re nodding your head in agreement. It will also help that you don’t have to ask out loud in a meeting (Yes, I saw that kill our teams reputation before).

The dirtiest and most trending acronym is MVP. No, its not Most Valuable Player, its Minimal Viable Product. Its the bar of profitability and value of the lowest part of the spectrum for success. If you read the link of the definition, it sounds great. At one time it was great when used properly but now it’s sales speak for “Doing the least for the most money.”

#5 – True Double-Checking.

Not just any people, but creators and builders who have worked (or still work) their way through the trenches and who have done that specific kind of work for many years. Watch the switch from effort to budget – they are difference in how salespeople sell but its not how projects are built. When a client asks a salesperson to lower the estimate by 25% it only changes rate, not time, time to create effective products that are properly tested.

#6 – Agile/Waterfall Hybrid Doesn’t work.

The basic Agile methodology and all its variants are wonderful when used properly. When it is used improperly, it becomes a huge mask of over the project. The team should be well-versed in the terminology and cadence of how Agile works or is supposed to work. It helps to have an Agile Coach that isn’t the Project Manager. Choose Waterfall or Choose Agile, but do not attempt to hybrid your process it will not work – Agile is based on small segments of flexible deliverables that can adapt using the backlog correctly. Waterfall is rigid and often requires ‘square shoved in round hole’ moments to meet deadlines.