Several times in my career, I have missed deadlines, delivered buggy solutions, or otherwise had failures and setbacks with my engineering efforts that weren’t really my fault. In two specific cases, unknown bugs were discovered in third-party vendor products in edge cases, and the bugs trickled up into our products in a customer-facing way. So from a customer perspective it looked like our products or solutions were broken when really they worked fine and it was something else that was broken.

It can be really frustrating when you are placed in a situation beyond your control where you seem to be unfairly set up to take the blame. This situation frequently appears in software requirements specifications. You can meet with your end users many times, provide demos, elicit feedback, give presentations, write down all your requirements with unerring accuracy and detail, and the customer can sign that document in blood. And yet when the product is delivered, they will insist it’s completely wrong and unusable and it’s all your fault.

In lots of project management training literature, or INCOSE-style systems engineering training materials, the types of challenges you will face in a PM or engineering lead role are presented to you and many times the solution is that there is no good solution. How do you deal with schedule slips because people are sick, or there’s a weather delay? How do you deal with missing engineering requirements because it turns out some external dependency didn’t deliver, or had a bug, or you find out some promised piece of functionality doesn’t even exist?

It’s really, really hard to stand up in front of a customer and take the hit when it’s beyond your control. It’s tempting to ball your fists and cry out, “It’s not my fault!”.  But is that true? If you’re in a leadership position, then the failure to deliver does ultimately rest with you, whether it’s something you could have prevented or not.

So what does that mean? Is it just hopeless, and you have to just expect failure? Partially, the answer is sadly yes, but there are things that you can do to prepare for and perhaps mitigate these situations.

Risk Management

Part of project management and engineering leadership is taking the time to analyze the project, the ENTIRE project, and identifying all those risk points. Especially in software development, it’s easy to overlook common risk areas:

• Are you ready to train users on the product? And I mean provide good training, videos and diagrams, not just hastily written MS Word documents
• Are you ready to fully deploy? Is the operations team ready to have all your resources provisioned and ready? They have people and time planned out for the release?
• Have you worked with IA, CM, customers, users, managers, the service desk, and all the many other possible people who could throw a wrench in the works at the last minute? Have you made sure they are aware of the project, the release date, and stand ready to provide whatever tasks and approvals are needed?
• Have you identified every place where you are relying on either a product or a team that is not your own? Every single external dependency (which includes things even like the operating system that your product installs on) is a potential for an unknown issue to appear.

You obviously can’t identify every risk and assign it a probability of occurrence and a mitigation strategy. But you, as the lead, need to be at least aware and monitoring all of these external touchpoints so that if there is a hint of a possible issue, you can get that tracked and communicated to your stakeholders and customers.

Customer Expectation Management

When it comes down to it, a requirements document is just a bunch of words on paper. Do your customers and end users understand what it is that you are REALLY delivering? It seems really obvious, but I’ve seen teams who thought they were delivering a piece of software, and it was a really awesome piece of software, but it wasn’t installed, integrated, or themed and branded, and from the customer’s perspective nothing at all was delivered.

Another example is a customer getting some piece of enterprise software. It was installed and functional on the agreed-upon date, but there were no user accounts, workflow configurations, initial data load/migration, so although the software was delivered on time, the expectation from the users was they could log in and start using it on that day, and that wasn’t really true.

Documentation, artifacts, and signed, formal memos and agreements are important for traceability and accountability, but it comes down to having real, face-to-face conversations with the relevant stakeholders and explaining to them what they are actually getting. You also need to listen very, very carefully and make sure you understand exactly what the customer thinks that the situation will look like on the expected dates, and then make sure what you’re delivering looks like what they are thinking. This is a challenging task, and takes a special skillset that can really only come from experience. It’s part crystal ball, part mind-reading, and part accurate explanation of the deliverable in terms the users can understand.

Grit and Gumption

When it comes down to it, however, the true measure of being a superstar is when you can get it done and succeed anyways. This doesn’t come from just writing a bunch of code. This comes from being able to look across all the necessary tasks that need to occur for a successful delivery and making sure that all those things are done. This is why many projects of significant size need leads that do more than just do pure technical work. You need to have the flexible and fuzzy skillset of being able to be a coordinator, a cheerleader, a communicator, a documenter, and a jack-of-all-trades that can do whatever task needs to be done to get the project completed.

A true superstar will be someone who can give the customer what they want in a way that makes them satisfied, while at the same time ensuring they get what they actually need in a way that solves their business needs. Being able to do this is way more than just knowing how to building something; it means being able to communicate with the customer, understand what they want, and building something and showing them that what they are getting is what they need and will help them succeed.