2 Steps to Ensuring Project Success

A few weeks ago we were involved in a hackathon in which one of the participants struggled a lot to get things working.  We ended up spending almost a full week trying to help them, but without much success.  We got our own stuff up and running in a day.  Not because we had everything ready to go, but because we understood the technology, had experience using it, and were able to come up with a workable solution in a matter of hours.

Essentially their problem was that they had outsourced critical parts of their technology to a third party.  The people we interfaced with had extremely limited technological competency, which means that they didn’t even understand the basics of what was needed to make their solution work.

Hours were spent in meetings trying to explain rather basic technological realities and there was much frustration and very little progress.  Eventually there was finger-pointing and blame games.

To be frank:  it is pretty clear that when you turn up to a hackathon with people who have no idea what they are doing, you can only blame yourself when your internal vision does not get realized.  Being unprepared and lacking critical knowledge has a price. This is how outsourcing has caused problems in project management. This is one of the risks challenges faced in outsourcing.

What is worse for them:  the impression we were left with was that we should under no circumstances ever work with them again if we can avoid it.  They lacked competence, professionalism, and common courtesy.  While the experience may have triggered soul-searching post fact (we will never know), the impression they left us with was very negative.

we’ve been thinking about doing a writeup about this because this is how we sometimes come across to our cross-functional teams or our customers.  Overly slow and bureaucratic because we often can’t solve things directly but have to go through third parties.

Since this was a third party we thought it might be easier to distance ourselves a bit and see the patterns more clearly without triggering defensiveness.

Many systems in Technology firms are outsourced, which means we have no actual control over them.  When something goes wrong, or when changes are needed, the work that needs to be done sometimes spans multiple organizations.  We are not self-sufficient in many places where we really should be.

Essentially the cost of getting something done increases exponentially with the number of parties involved.  Which leads to slowness, and in many cases: that people give up even before trying.  We see this in ourselves:  if a problem requires us to deal with more than two different organizations, we know that the chances of success are really low and we are inclined to not even try.

What made me write this today is that I came across a formulation in the minutes from a meeting in which Technology firm is trying to collaborate with other organization and they simply can’t seem to do it.  The sentence that triggered me was this:

    “It seems that collaboration is challenging due to resource situation among project partners, and that availability of data is challenging due to outsourcing of operations and IT solutions.”

The sad bit is that this sentiment has occurred in some form in every single cross-departmental project where one part of firm wants to do something with another department of company that we have been involved with over the past couple of years.

We tend to harp on about solving the basics first.  we’ve done that for nearly a decade now.  There is a reason for that.

We talk a lot about big data and about machine learning and AI and whatnot.  While this is exciting and glamorous, it isn’t even possible unless you solve the basics.  Like how you provide access to data in a meaningful manner to other parts of the organization.  we’ve worked for organizations that failed to solve this.  we’ve also worked for organizations that succeeded.  Where these basic things were sorted out there was invariably a Cambrian explosion in products due to productivity gains.

I’m not laboring under the illusion that accomplishing this in huge firm is easy.  But I do know that we will cut ourselves off from many future opportunities if we just ignore it.  As we have mostly done for the past decade.

In order to know what constitutes “in a meaningful manner” you have to be somewhat technologically competent.  You actually have to understand what researchers, developers etc need to do in concrete terms.  You also need to develop a certain amount of empathy with the people who do things. We need to learn how can communication between departments be improved to avoid conflict.

Not 4,6 or 10 but only two factors that lead to successful projects and how to improve cross-office collaboration skills. These are only two ways to build collaborative teams:

• The first is to actually listen to people who do stuff. When a problem is raised, don’t just reflexively become defensive and try to deny their perspective.  Don’t think that the way we do things today is the only possible way.  Be open to the possibility that we can, and perhaps should, change even very entrenched practices.  Believe in what customers/users say and try your best to understand what they are saying.  Put yourself in their place.  Don’t assume that you know why something creates friction for them.  Understand.

• The second is learn how to do basic stuff. Learn how to write simple programs.  Learn how to write a program that consumes an API, for instance.  Try to do what your “customers” want you to do.  Put yourself in their shoes.  Figure out where the friction points are.   If you need to spend a few weeks learning how to do what your customers do:  do it.  If you are not willing to do this:  why should they trust you?  If you are a leader you should be able to do at least one or more of the jobs of the rank and file people who report to you.  If you can’t do any of their jobs: it is likely you are under-qualified. You don’t understand what your organization does.  Modern times places higher demands on leadership than just being able to hold a title.    Expand the scope of your competencies.  Always.

Let us know your thoughts on self-sufficiency, innovation and leadership in the comments.