The Undercover Adventure (Part 4): Rabbits chasing running carrots.

I sighed once more as I read my email and with furrowed brow considered the end result of his email. It would not have proven to be so frustrating had this been 6 months down the line and a trail of circumstances pending to predict its arrival. Instead it arrived without prior input or conversation and held consequences for the current process. I knew then that something I had run into before, was not a one time (and more so one person) occurence, but rather a state of motion for business.

Simply put, I have spent the last two months building up the right processes and structures for archive that I was tasked to build. While I didn't agree with the original intention to have a hardcopy archive as it places severe limits on accessibility when you compare it to a digital archive, I put together what was necessary to create that (with a digital copy that would mirror the archive just in case they should change their minds about it). The email that I received essentially took away the majority of the resources that I had been promised and additionally informed me that the scope of what the archive had to cover was now far larger than before. There are certain parallels for me between this and what I have experienced on software development projects.

Have you found that when dealing with the business that they seem to change their minds a lot? (Irrespective of previous agreements made and discussed) That beyond the meeting, while you head off back to do what you do everyday, when you see them again that suddenly things are different. I have experienced this in two completely different companies and it is something that has brought me a lot of frustration because I didn't initially give consideration to a forces that create it.

When I started in software development my assumption was that the playing field when making decisions was level. That the team held its own when it came to decisions and giving direction. A few projects later down the line and I found myself somewhat disenchanted. It seems that software development as a project lacks solidity in the clients eyes. Whether the lack of it is persisted through a weak project manager or lack of appropriate business support structures, the fact still remains that software development investment isn't understood and at times, very little respect it paid to it.

I do believe that business people don't generally understand that nature of the machine and the importance of proper planning and preparation in software development. Perhaps this is the case because so much of what we do is hidden behind the scenes and isn't something that you can pick up feel and touch. Here on the mine it is far easier to convince a supervisor that you need a particular item because you can pull out the schematic and show you him/her where it would sit. If that was a piece of software it would most likely be brushed off to be included in a meeting somewhere. However, when the business does want a change, there is an expectation that that change should happen quickly.

Also, I do believe that business assumes that software development can change course as quickly as it takes to change direction in step and face the other way. They are not aware of the coordinated actions necessary to produce the functionality that sits underneath that button called submit. Thus, the consequences of changing functionality quite regularly, even in an agile world, without consideration of necessary time to be allocated can cause technical debt (amongst other things) because of this need and expectation to deliver. Again, there is very little recognition given to tasks that address architecture and refactoring and it often is done between this and that.

Which brings me to addressing the issue I mentioned in brief above. There is a disconnection between the software development and the business when it comes to the choice of end goal and perspective on process. While there are techniques and approaches that do bridge a part of that divergence. I have realised that even our most earnest and proactive efforts would not be enough to close the gap. I believe this for following reasons.

• People reveal information in layers when they talk about something.
• That information changes as the business changes and that change happens far quickly than we think.
• We are never dealing with one perspective of the business.
• We lack the power to enforce consistency because we promise to deliver something that aligns to their business needs.
• Those business needs change faster than we can build.

There isn't a clear alignment between our goals as builders and their goals as desired state descriptors. If this were the construction industry, the end result wouldn't be pretty. There would be a room here, another room over there but no passage to connect them. However, the front garden looks great and there is an outdoor shower, but no water.

I want to be clear about something when I speak of information. I am not only refering to that which is included in a business specification. I am refering to all the information that is fed into a project. Whether it is related to who is on the team from the business side, who has accountability for certain decisions, which dates are important for what and so forth. A lot of emphasis has been placed on specification side of things (and rightly so) as it is probably the most obvious place to recognise that this disconnect exists, but I do think its important to always have in the back of mind that it can happen with all the information you receive.

So, what can be done about it. This is where risk management through politics, power and creating the right facade makes a difference. You will not have control over the business in any way, or over how the information is given to you in that it will come through in stages throughout the lifecycle of the project. You will need to have enough power in the eyes of the client to stop and start and pause parts of the project to accommodate for the influx in information or requested change in direction. You will need to get to know the business, learn to anticipate change and understand who the people are that really make the decisions because those are the people that you will need to address when it comes to responding to the business. I know that it is easy to say that all of that exists in a contract and that it can be used to “enforce” (for lack of a better term) the terms of engagement, however that should never be your first point of call. Pardon the abrupt ending, but time is short this morning and I will continue to this next week.