Like the free lunch adage, there is no such thing as an easy task. If the task were easy, the client would have done it themselves. Data suggests that people and teams learn faster from difficult tasks. This is not to be confused with ‘Fail Fast‘ concepts, since failure is expected and managed as a learning experience. If a project deliverable seems 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. Oftentimes risk is removed from projects by removing the effort for a healthy project.
Lucky for some us, many early symptoms of a southern bound project can be corrected. The earliest and best recognized symptom is the appearance of being easy or pleasantly quick. Remember the old adage? If it’s too good to be true, it usually is. These easiness attributes are often built into the estimate and make your company’s competitive bid lower. Easy tasks are clouded by a fog of ignorance, inaccurate definitions, bad or misused syntax, artificial time pressures and ‘sales-cowboy get-r-done mentality.’
Sadly, the once-burned folks are really good at picking up the language. How many times, have you heard a team members say something like, “That’s an easy fix. It will take 5 minutes” or the “It will only take…”. Afterwards the team-member goes dark, misses several stand-up meetings and his really hard to track down afterwards. The easy fix? The easy fix ends up becoming an effort that takes days instead of minutes. Ultimately the project timeline bounces around so much that the inefficiencies affect surrounding team members, stakeholders, client relationship and ultimately the burn rate of the budget.
The tips below are not the silver bullet, but they should help you spot the patterns of easy that will hurt your projects and the reputation of your company.
#1 Treat English Like Code.
I can’t emphasize this first rule the most. A good number of companies will see human copy completely different than their approaches of code development. Google began to score human readable text for its metrics in 2011 when launched Panda.
The seeds of ‘easy-loss’ are often sown in a scoping documents by people who don’t know how to write scoping-language documentation. Sometimes they are good salespeople/managers but simply aren’t good writers. English is a marvelous language and contains all the nuances of a crafty CSS document which gracefully tag elements. English can nest concepts and it can cascade meaning, architecture and properly add timing metrics.
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. For example, “Our code will be tested against all current browsers.’ Watch for words that don’t frame up their effort over time and which make more effort – “The web project will adhere to the most up-to-date browsers.” Sounds great, but the promise sounds like the project will be tested for 10+ browsers during an extended period of time. And is the browser Canary included in all browsers?
#2 Never copy a copy
Instead of starting with a fresh template of a scoping document, someone will suggest, for the sake of speed, to simply edit a past project scope document. The copy will be the first approved document, but will lack any additional details or addendums of change in the past project – these might be: Change Orders, Budget reports, Scope Shift, Backlog Notes, etc. When copies are used of past projects, the ‘success change metrics’ were never added back to the originating document. If you do have copy a copy, be absolutely clear in the risk you are taking and manage it correctly with your eyes open.
#3 Avoid Language-traps.
These might be typical verbiage or reserved words. Often nobody will hear the term ‘easy’. The language that is used is hidden by other terminology – ‘Lift and Shift’, ‘Migrate Content’ are a few well used. Some of the bigger projects will use distanced-effort like, ‘We don’t have to worry about that…. the [other area, person, or system] will pass the calculated variables to our client code.” Pay attention to the word ‘only’- it’s used an inference of low effort or cost. “It’s only a logo”, “It’s only a tier 3 implementation…” My favorite and the deadliest is “Don’t work about the [task], the client will be responsible for doing that [task].” The last statement is deadly since the task is un-defined and we don’t know who is doing the actual work which others will be dependent upon for success and timing.
#4 Acronyms aren’t words
Larger companies will mask some of the easy tasks as acronyms and used repeatedly in text also creates dense meaning to text that may seem lighter. Before promising deliverables with aggressive deadlines, do your homework in that industry to understand the hidden meaning in the acronyms used in your clients’ text. It will also help that you don’t have to ask out loud in a meeting (Yes, I saw that kill our teams’ reputation once – SDK).
The dirtiest and most trending acronym is MVP. No, it’s not Most Valuable Player, it’s Minimal Viable Product. Its the point where profitability and value meet on the lowest part of the success spectrum. If you read the definition from the link above, the concept is great. At one time, MVP was great when used properly in its originating context, but now it’s sales speak for “Doing the minimal for the most profit.” The project also seems to have the whole team focusing on minimal success factors instead of high value.
#5 True Double-Checking.
Estimating is never easy and is always competitively rough. Regular folks shouldn’t be estimators and not everyone is great at estimating. Estimating should be reserved for creators and builders who have worked (or still working) in the dirty trenches of delivery. These specialists have created the specific kind of work for many years. To add true double-checking, the double check should be conducted by a creator of the same caliber of the first estimator.
#6 Mind the gap.
Here is where effort and value a very closely and dangerously are used as one term term. It’s a path of failure if it’s not managed correctly.
As effort and value blur, the game changes a bit. A gap will form when the effort-amount in dollars is challenged against a budget. This gap forms due to how salespeople ‘sell numbers’ and how ‘projects are built’. It becomes a dirty game of chicken. It goes like this: A company will complete it due diligence and produce a properly scoped estimate based on value of producing a project correctly aligning to the needs of the business expectations in its market. A client will then ask a salesperson to lower the estimate by X%. This is where sales response is crucial. Salesperson A can keep the number and sell the solution and reasoning based on the value platform and challenging the budget. Salesperson B will accept the challenge to reduce to rate to fit into the lower budget. B response seems to be the choice without risk, but in the end, it’s the riskiest choice. B is based on cost of the same value of A but ultimately unachievable based on the fact that effort was removed to comply with the budget. The clients’ expectation is that they are still getting the original value of larger number when they are not.
#7 – Don’t Mix Agile & Waterfall.
The basic Agile methodology and all its variants are wonderful when used properly by trained and experienced employees, managers and stakeholders. The team should be well-versed in the terminology and cadence of how Agile works or is supposed to work. Companies goals can stay on target more reliably with a qualified Agile Coach that isn’t the Project Manager.
Stakeholders & managers should choose Waterfall or choose Agile, but do not attempt to hybrid a development process. When Agile is used improperly or in a hybrid version of Waterfall, it becomes the opposite to its original purpose. Agile is based on small segments of flexible deliverables that can adapt and improve using the backlog correctly. Waterfall is rigid and its success is based a concrete plan that doesn’t change over time. Which is great as long as there are no changes, surprises, error, hiccups, etc. Waterfall will employ ‘squares in a round hole’ moments to meet deadlines based on early promises that have expired past their freshness date.
I am a huge supporter of all the kinds of Agile. The future of management and delivery of the best work will from organizations which follow the ‘Spirit and intent of Agile.’
JVS 