28th July 2014 by dan hamilton
What is the biggest determents of project success or failure? Here I will propose three factors that are more fundamental to a projects success or failure than methodology.
Agile and Lean methodologies are by no means new, yet they continue to be in Vogue among many businesses and organisations who deliver software development projects. For some they’re seen as the wholly grail, resonating as a panacea for all project delivery woes. Less documentation, less bureaucracy, more real work. Unquestionably a sure recipe for getting things done, right? It’s comforting to know Project Sponsors can finally sleep safely at night without fear of being doorstepped with an exception report shaking them down for princely sums from the magic contingency pot.
But we know that Agile projects also suffer from the same issues of cost and time over-runs, perhaps disguised as different symptoms and often in a way which can be identified earlier. Ever heard “We are on track for completing this sprint as planned but the release backlog has increased significantly?” Clearly methodology can assist and improve the way we deliver projects, but here’s three things I propose trump methodology.
The need for good judgement within a project is paramount to its success. The ability to make the right call (or perhaps avoid the bad calls) on limited knowledge in endeavors that enter unfamiliar territory ranks at the top of this list. No amount of conformance to process or methodology is substitute for sound judgement, and in-fact knowing when to stray away from the rules is invaluable. Likewise good intentions and hard work can help achieve a goal, but where the project outcome is the defining assessment criteria, collective judgement of the project leader and team will be the primary success factor.
Judgement is unfortunately highly intangible and somewhat difficult to measure. However most judgement calls fall into one of three domains:
People. Getting the right people in suited positions in the team and aligning their growth and success with that of the project’s objectives. Equally important is knowing when and how the team or an individual may fail. Good judgement needs to stretch beyond decisions involving the project team, and must take account for the wider organisational and contextual considerations.
Strategy and Tactics. What should be done and how? Working on the wrong things and/or using ineffective methods is probably the biggest killer of project progress (assuming fixed scope). Each project is by definition a unique challenge and thus requires judgement as to how best to tackle it. There are of course opportunities for reuse, standardisation and best practice that can and should be used as accelerators, but this needs to be a pro-active decision as opposed to following a process for the sake of conformance. Ergo the choice of methodology for a project relies on the judgement of those commissioning or delivering it.
Crisis. Dealing with the inevitable crisis that projects are a magnet for, often under considerable time or pressure constraints. Damage limitation can often be a key project success factor, though it’s important to understand why and how the crisis came about before assessing if the fire fighting was as heroic as first appears.
It certainly feels that strategy and crisis judgement are easier to master than ‘people’ judgement, and that many of the decision calls of the former are massively dependent on the latter. A judgement that does not successfully execute must be considered a failure no matter how smart the strategy.
Another interesting topic is how well can this skill be developed by people; is it something that comes with experience? Can it be trained? Or is it something innate to only certain people?
The ability to prioritise within a project of work is a simple and sensible idea, surely we’re already doing this? We already have great tools to prioritise requirements at the beginning of the SDLC via MoSCoW and also in Lean with the Kano Model. But then the project starts and guess what; today’s business needs have evolved from yesterday’s requirements document, which by the way were recorded when we knew least about the project. Standard. So Waterfall has change requests to deal with this and Agile has the notion of freedom for the product owner to change requirements for upcoming sprints. We’re in control right? Wrong. More and more is added to the project, either by explicit agreement or by hidden change. The net result is an ever-moving schedule as the finish line gets pushed further and further away until one day the team can no longer see it and begin to care less.
A far more effective strategy is to continually prioritise and (all else being equal) hold your original schedule by descoping other less critical work. Why does this work?
Complexity is exponential, not linear. Adding that extra stand alone widget is not just an extra week Dev. It is holistic and interconnected and will impact elsewhere, you just don’t know where yet. Keep complexity limited and you can achieve far more with the same resources (see “Simplicity” below).
The delivery teams perception of the road ahead is more stable and that a give and take relationship exists with the project’s stakeholders. The words “Thrown over the wall” do not get muttered…
As a client you are empowered and forced to make key decisions regularly throughout the project as to what’s really of value. As a nice bi-product the chance of building the wrong thing is greatly reduced also.
Side Note: I strongly suspect this is probably the leading factor as to why Time and Material projects generally have better outcomes vs Fixed Price for all parties as the requirements owner is making informed decisions in the always ‘be prioritizing’ mind-set. We have achieved significant project time and cost savings with clients by empowering them with the confidence and skills to effectively prioritise in-project. Is this what Agility is really about?
Simplicity is often overlooked, or should that be simplicity as a tool is often misunderstood. And if it was simple to do then we wouldn’t need a project to do it. Turns out achieving simplicity is actually quite hard to do. Simple does not constitute easy. Being able to simplify any part of a software project can have massive benefits. Technical solution, team structure and reporting are all candidates that can and should be simplified wherever possible.
An example by way of a war story:
Last year Emagineers were brought into a failing E-commerce start-up project which was on its 3rd attempt to launch and in a poor way. Much effort and thought had been burned by the incumbent developers in trying to import and process tens of thousands of products from disparate affiliate data sources. The business rules were complex and evolving, the data was voluminous and inconsistently formatted, and the technology stack was both new to the developers and a little too bleeding edge.
Our major contribution to this project was to bring simplicity to the table. Admirable ambitions to have a fully automated product import process from day one had facilitated a huge ramp in complexity. But actually shoppers don’t care about where or how the products got in the store, more that you have a suitably large and relevant selection. It was clear that we should remove as much complexity from the import process as possible. Out went parallel processing, out went funky middleware and queuing systems, out went the notion that this was a critical hard dependency. In came a definition of what the MVP needed to do, and we built and manually triggered a batch process for product import. This resolved a three month issue in two days and meant the project was now unblocked and able to launch.
Side note: It always amazes me that us techies believe we can and should automate everything, yet fail to realise if you can’t define and explain how to do it manually, you aren’t going to be able to automate it.
How does the success of your software projects conform or contradict with the above three influencing factors? At Emagineers we put these principles into practice on a daily basis and find this greatly benefits our projects.
Emagineers : E-commerce Experts and Web Development Specialists
Call us on +44 (0)208 088 9020 or email us at email@example.com