My days are taken up talking about projects. While that might cause some to wonder what deity I might have offended to warrant such a fate, I actually like it. We do enterprise content projects and we get involved in big, complex projects that make a difference to our customers. Often, we come in after things have started to go badly and play Ghostbusters – “Who you gonna call?” Those engagements are especially high-risk and difficult, but they put me in a privileged position to see what matters and what doesn’t.
What I’ve learned is a little surprising when you consider where customers and vendors alike place their emphasis and effort and, consequently, take their risk. Risk isn’t the important thing, it is the ONLY thing. No one will remember the exact price of the project or specifically how long it took. But careers are made and lost on whether the project completed, delivered value, and satisfied the users. That means vendor careers as well as customers. We live or die based on our reputations and we spend an unbelievable amount of time assessing the state of projects and their trajectory. If we can catch trouble early or spot a project that we don’t think will succeed and avoid it, we can save our reputations. Sometimes that means passing on business that could be profitable. It is a tremendously difficult call to make, but we have done it repeatedly. We can never be sure it is the right decision, but we have to try.
After making the call on what projects to do and how, and seeing customers do the same, a few areas have emerged as critical points that can lead to success or failure. So, what are the key elements that make projects go off the rails?
What can go wrong?
This topic is huge. We, as a company, spend more time on this issue than we do on sales or finance or systems.
Experienced people make projects work at every level. Architects, developers, and managers can all bring a project down in dozens of ways. On the other hand, someone who has lived through good and bad projects can see the signs of trouble and avoid it.
I recently saw an inexperienced project manager approve a couple of key developers time off and then go on to approve a go-live on a project release. Fortunately, a more experienced manager noticed the problem, made him adjust the dates and saved me and the customer from a crisis.
No significant project can staff with senior people at all levels. Both the cost and logistics are prohibitive. In fact, I’d suggest that junior people often drive innovation in technology and process and greatly benefit the project. The key is to place the experience at critical points to catch mistakes while ensuring cost and innovation with talented junior staff
We recruit using a network built on a total of thousand work years of effort. One thing I hear repeatedly from our best people is that they like working with the right blend of talent and experience and that they make employment decisions based on the quality of their coworkers. In short, both talent and experience tend to flock together.
One note: The project manager who got saved from a mistake worked directly for a customer. The problem can occur in either organization and both vendor and customer need to think about the experience.
It takes years to become a competent architect. Talent, study, practice, and endurance are all essential. I freely admit that I am in awe of our best architects. These folks “got game”!
Unfortunately, projects often underspend or under configure architecture. The result can be catastrophic. The motivation for this mistake is always either cost or speed. In both cases, the project ends up sacrificing the very thing they were trying to save.
A few months ago we did not get a project based on the amount of architectural work we proposed. The customer wanted about half of what we thought was appropriate. While there is always room for reasonable discussion in configuring a project, this was a very large gap. I was relieved that we weren’t selected because I couldn’t have taken a project that was organized like this. I’m sorry to say that we may have been correct and that there are already indications things won’t go well. I hope they adjust course. The business might not go to us but, it would be a shame to see the project crash.
This word has many meanings. Some take it to be the same as compliance. I don’t mean that. I mean the engaged oversight of an enterprise project by the customer and vendor(s) at multiple levels. Regular meetings and shared responsibility are important. The biggest failure occurs when managers take an attitude of “gotcha” governance. While enterprise projects often have SLAs and other protections and penalties, it is not in the projects best interest to trigger them. It is incumbent on both parties to actively participate in well-planned governance meetings and policies.
It is especially important for the provider to listen to the customer’s concerns that are revealed in the process and not adopt an adversarial posture. We have excellent projects with the US government in which the governance meetings and procedures are tough, but also a great example of teams working together to respect the process and each other. As a result, these projects are remarkably efficient and win awards for their output.
What doesn’t matter?
OK, everything matters. Some things get an awful lot of attention, but I can’t see a discernible difference in the outcome. Mind you, I’m only talking about project outcome. There are other factors in play that may be important to the organization like legal compliance or national security that I don’t mean to minimize. That said, organizations too often lose track of why they do things and start to believe that they impact project outcome when the often don’t.
You can probably imagine that I see this topic handled in a variety of ways. From closed “friendly” discussions to full-blown government RFPs. All are legitimate in the right circumstances. I’m not trying to address unfair, or shady, dealings. Those are, happily, rather rare.
I find that selection process and project success seem to be independent of each other. In fact, I could argue that the more rigorous processes with weighted scoring and rigid response requirements tend to reward vendors who are better at administrative responses and increase the risk of making the wrong selection.
The truth is that I’m not against any particular selection process. We work hard on them and win our share and more. I would say that the process does not seem to correlate with success. Truly understanding technologies, experience levels, and project management capabilities does seem to indicate success. Too many organizations staff selection processes with people who don’t have the understanding to make good judgments or are too far down in the organization to have the right perspective. If you are part of an organization contemplating a project and have a selection process to deal with, consider you staffing of the selection carefully. The process won’t help you succeed, your people will!
Some organizations have a legitimate need to have a nationality standard for their projects. Governments (The US government being the largest customer in the category) make this demand based on national security. Some financial organizations require it for certain applications. That is, of course, their decision and a legitimate one under those circumstances.
Unfortunately, some organizations have taken nationality to be a proxy for quality. I don’t see any truth in that. In fact, it quickly devolves into using inferior resources on projects just because they are domestic. If you want the best project, use the best resources – period.
We have found that the most successful approach blends nationalities. First, because they use the very best available. Second, because a certain amount of diversity always works to the project’s benefit.
What about price?
Project cost always matters. Money is a finite resource. That said, price is often your worst enemy. Far too many people make decisions based on blended rate or category cost and ignore all the other factors. Factors that impact success or overall cost and have relatively little to do with price.
Consider the example of the organization that configured too little architecture resource that I described above. People that lacked reasonable experience made that decision driven by a price comparison. Their project now appears to be heading for trouble. How much will the recovery cost? What careers will be set back?
I’m not saying to pick the high price. I’m saying that price isn’t a great indicator of success. Any organization is much better off temporarily setting price aside and determining the best project composition and partner to make it work. Only then should you come back to price and negotiate one that meets your needs. Approaches that say price is a certain percentage of scoring (or the like) invite unscrupulous organizations to manipulate price, staffing, and Statements of Work to take money for bad projects.
My organization makes a good piece of its living coming in after these kinds of disasters. While we are grateful for the business, I’d be just fine if customers would do the right thing from the start. That includes putting project success first, evaluating project risk in your selection process, looking at experience as the critical factor that it is, and making your most experienced executives a key part of your project design and vendor selection.
There is no short cut to project success. Fortunately, it is also not too complicated to maximize your chances. I always hope to work with the kind of organizations that do it.