Building software shouldn’t be this hard!!!

Every time I work on a software project with a new client, there is a battle that continually brews that makes the process harder than it should be. And that is that the client doesn’t trust the process.

Think of it this way; if you were to build a home, the builder takes you through the process of architectural design, laying foundations, putting up frames, roofs, plumbing, then painting, bathrooms, and finishes etc. You would never question the builder as to why can’t the painters start even though the foundations haven’t been laid. Or to draw more of a similarity to software, why can’t you have that 5th bedroom and 4 car garage, after the construction has finished and the painters have finished?

But this is what we seem to suffer daily with software development. The issue here is not the fact that there is still a lot to be learnt from how software gets built, and more importantly, that there is many more approaches with software being built than a home being built. The issue is that the customer just does not trust the process the team is taking them through.

So how do we resolve this?

And this is a difficult question to answer. Building construction is a mature process, that has evolved over thousands of years. And in some ways is something that is instinctual to us as a human race (we need shelter right?!). Whereas software development is at best 50 years old, but realistically is something that most organizations (and people) have been exposed to for less than 20 years, and in that 20 years have been exposed to several different methodologies, all with their own flaws.

At the crux of this is the relationships. The relationships with vendors, customers, developers, subject matter experts, relationship managers and stakeholders. If anyone is going to trust a process, the people must trust each other. If not, the end result is nothing short of carnage and an unhappy result.

But the driver to this is that there will always be a dominant and a submissive here. And you get both types, where the vendor is at the mercy of the customer (dominant customer), or the customer is getting beat up by the vendor as to how best to deliver the results (dominant vendor). And neither of these is better than the other, as it depends on what the project is all about. More importantly, you can’t have two dominant parties here. It won’t work – that is where you get the ‘butting head’ syndrome.

So, early on, it is good to try and identify who is playing what roles, even if it is something that is unsaid but understood (which is usually the case, because no vendor or customer is going to fess up to saying “OK, your the boss, tell me what to do!!”). It is important as a customer, what kind of vendor you want to work with; do you want a vendor to bring in their tried and tested process, that they claim will revolutionize software development for your business, or have you got this thing down pat, that you want to be telling the vendor how to do things, and they are just bringing all the technical skill? Because this decision, is what you should be basing your vendor selection choices on.

What about if there is no vendor, and its an internal team?

In some ways this is easier, but trickier. Because you have the same psychology that you need to put in place. Is the development team the type that will drive a delivery based on their processes, or do you need to instill your processes on them, and they are just bringing the technology skills to the table? The only real difference here is that this is something that can be defined by a project sponsor, or senior representative to the project. ie/ “Mike’s Team did a great job on that last project, everything was delivered as expected, on time and on budget. We are going to use the same guys, and they will bring the same process to the project for us”. The rules have been set here and it has been defined that the project team have the dominant, lead role.

So what does this all mean?

After you decide (or define) who will be the dominant player, you need to understand that the dominant side is actually bringing the process into the mix, and as a submissive, you MUST trust this process. If you have your doubts or objections, sure it is only fair to have them voiced, but don’t fight the process for the sake of it. Trust it!!!!

There is nothing worse than being a team leader on the dominant side, with another “wannabe” dominant leader, and other than disrupting the project, it adds no benefit at all. But this can be frustrating as well if you are the wannabe in this instance and really believe that things are being done wrong. What do you do? Importantly, is not to start battling, it is to build on the relationships that were mentioned above. Those relationships need to be encouraged, nurtured and grown, so that as a team you can all move forward. Even the two leaders (be it that one is a wannabe).

I have been in these environments, and when you are on the other side of it, it can be challenging, but it is important to voice your concerns in the correct ways and to  reduce the chance of confrontation or hostility that does no-one any good, work on this together and in a way that gets your voice heard. If this is not working, then right from the start the wrong decision has been made.

But if it is working, TRUST THE PROCESS! Let it run its course and see whether it will actually start to work to the benefit of the organisation and everyone in the project.