Project Planning: More Art than Science
There are many consultants and vendors alike who tout their project delivery as “agile” or always “timely”. Many mention, too, that they have nearly 100% success and 100% track records in delivering projects. One of my favorite claims is that 100% of our clients are referenceable. My daughter and my pastor will give you 100% references for my firm too – so what?
If this were all true, why would they have to pay well over $200/hour for someone who has any real experience – above $300/hour is very common. Software company leaders charge well into the $400/hour for – due to being on 12-15 projects themselves – doing nothing more than sitting on weekly calls and stopping by once a quarter for a few days, adding little to no value.
Have I been on projects that have gone really well? Yes! Have I been on projects that have rolled off the rails before even getting started? Yes, I have! Everyone, apart from the client, knows it and just rolls with it. I know why this happens, and it won’t happen with my firm. Independence, in its true state, provides trust.
I have seen projects achieve nothing for a year, and yet the client lets the consultants bill away until someone decides it is time to work. As I have said, and will say again, there are many consultants staring at their computers, few knowing what to do, when, where and how. There are others limping along, deflecting and attending as many meetings as possible to buy time.
To claim 100% success, as blanket statement – or even anywhere close – is a fallacy in a market that cannot meet more than 70-80% of your requirements. There are countless bolt-on classes of software, too, we have articulated, that can increase this percentage to the 85th to 90th percentile of expectations. Many clients are provided a nudge – a hint – that they may need these additional bolt-on systems.
Before the project kicks off – from a combination of not really knowing the system you are buying, internal perception and sales approaches – the suggestion that we can make one system work or that the vendor will complete their roadmap timely, or that we can solve this issue and 38 more with an extension, is generally setting oneself up for disappointment.
After project kickoff, many companies in the last year realize they must have, not a nice-to-have, these additional systems. A word of wisdom to consider this risk in your project planning. Based on these facts, when someone says they are 100% successful, it is either the companies who are only trading financial futures or one physical instrument at one or two locations. I am thinking of a project that is claimed to be 100% successful because it was below budget and was delivered basically within 90 days of the original due date. Sure, if you remove over 60% of the reports, you can hedge to that outcome.
Then, there are those who tout “agile”, when it’s really just chaos. If you are working on so many things at once, such as chasing referential data while you are in the design phase, it is certainly more chaotic than productive. In reality, that kind of chaos drives lots of rework. Re-work costs you time and money.
At the same time, scope creep occurs. It goes back to those original scoping and requirements that were gathered using the same coffee stained templates that have circulated from project to project. Since consulting firms and software vendors are just moving the process to a “software license close,” these initial steps, which are critical to setting expectations, are often setting many projects up for failure before they start.
Often, they push you through the phases to, “just get it done,” and move you toward a sale. But in my model, all of that comes later.
Before we really jump into project execution and focus on the critical areas of success, I would like to start here. Projects are prepared poorly for countless reasons – project leaders are assigned from other non-trading groups, with little time to work on the project and project tools are rarely used beyond the 25th percentile.
Oftentimes, the people putting the project timeline together are ‘thumbing it’. You can’t predict with certainty, and when all of the external parties involved, consulting firms and software vendors feel bad that you wasted your entire holiday break creating a 1248-line project plan that has absolutely no chance of success.
I have worked on projects where the requirements went into the thousands. And how far are those requirements going to see the light of day once the project begins? Rarely, save the few who actually phase their projects and do a requirements refresh in each phase.
One can discern a client’s maturity the minute they want to do an overhaul of their entire financial and physical trading business. Not unless you are a small shop with few trades can this be done well.
With 1,000 high-level project tasks, and many not assigned, one should not be astonished when deadlines are missed. Getting a project task to 90% complete is only half the work. The last 10% is the hardest part.
Creating a perception of “done” is one I see used all too often, to make it appear as though projects are creating momentum when in fact they are not. The perception of momentum might be good enough for many, but it is not helping the project in any way. The perception of “completed” or “nearly completed” might meet the project roadmap, in the interim, but eventually the real outcome surfaces. Clients are disappointed and consultants are the only ones who win.
There is a simple thought process, before I suggest the critical path to simply follow, and that is to break the planning into short- and long-term objectives. The key is that the short term – for the next 2-4 weeks, at most – should have specific people working specific tasks that align to the critical path I suggest. Sounds intuitive, but most projects don’t get to this level of delegation, as people are flying all around the 35,000-foot level hoping something will get done by someone. Only 20% of the project staff do 80% of the work.
There are those who will say that the 20% who really deliver the work don’t matter. When I first heard that, I thought that was absurd. Now, though, I can see if you follow what I am suggesting below that the 20% really doesn’t matter if you manage the project properly.
There are examples of people who, having delivered countless projects in their career, on-time and on-budget, get frustrated that they were not promoted to CTO of a large company. Projects are hard, and sometimes even the ones who deliver well get a hardnosed reputation. That is what you asked them to do, they delivered it. The project team felt like they were run over to meet the deadlines. I assure you most of the people who are working on subsequent projects appreciate it and wonder where that go-getter went – because the project they are on now is dragging along with no end in sight. Bring the wisdom back please.
So, how do you balance deadlines with people and the human nature that always surfaces? I have this concept of keeping it simple, and keeping the project lean, especially early on.
Assign tasks and deadlines with short durations and find out who can deliver what, when and how. Find out quickly who is really doing the leg work and who is deflecting so you can weed out the politicians. There are people great at deflecting to the software vendor, or the client. Let me be clear, in the consulting world it is not just politics, but a sporting event, every single day. At 32, I would have been frustrated. At 51, I laugh.