- suggestions for better outcomes by really working together
Part 0: Typical problem situations
The question is how to really succeed with your projects and initiatives, to elevate the business. I’m not just talking about staying within time and budget constraints. Take Microsoft Word, for example. It was launched late and cost more than was budgeted for, but I’m sure most people would agree it was a success. So, how is real success achieved? There are many suggestions and in my 30 years as a consultant in software development, I have created a list of what I think really matters! I will share five of those with you in this blog series, and I’m looking forward to hearing what your suggestions are.
Let’s start by discussing four different situations which I think will help to set the scene. Let’s see if you recognize any of them.
The first situation is from when I was running a workshop about software development and Domain-Driven Design [DDD] for a bunch of military grade security experts. They asked me how new development initiatives are normally started in my field. They were shocked to hear that we didn’t start every initiative by doing a full scale security assessment and information analysis from a security perspective. “That’s incredibly reckless!” they said. I was as shocked as they were, but for a different reason. To me, this was like talking about, say, how big a door should be, without first establishing a context. Who said we were talking about a house - it could just as well have been a bike.
Then we have the top level manager who decides to buy a workflow package off the shelf, before anything else. When the needs are discussed with the domain experts, the conclusion is that there is a need for collaboration support, but it has to be very ad hoc and different every time and mostly about working on the same data.
The third situation comes from a discussion that took place while hanging out in the operations department one day. I mention a potential upcoming initiative to a hard-core operations professional. She becomes pretty irate at not having been asked about the kind of servers needed, the overall capacity, the framework versions, the SLA and the ports to be used. There is nothing to tell since so far it’s just a vague idea, nothing more. She lets me go when she has made it very clear that before anything else, she will be the one to make all the decisions after having received all the detailed information!
The final situation is the example of a newly recruited but very experienced project manager who comes in to run an upcoming initiative. He spends months of work creating a documentation tree and adding a lot of documents. But none of the documents has any content, only headers - because they are templates. Six months later the initiative still hasn’t been described, let alone started…
This is the tip of the iceberg. All these people mean well and are professionals, yet they still managed to run smack into a wall all too easily.
And just so as not to make it sound as if we developers are sitting on our high horses, we might also suffer from similar problems. Who wouldn’t find it even a little bit thrilling to change to the latest and greatest UI framework every third month. And to use Kubernetes and Kafka and…so we can deal with Twitter scale load from day one. You never know… Or the new storage technology that will make the CAP theorem obsolete or to start using the technology that will help services start in a few nano-seconds or even in negative time? :) Or...
Those situations were wrong in different ways, yet there were similarities. To focus on one speciality in a vacuum is not typically a good start. You will achieve “busyness” instead of “business”. It’s similar to riding an exercise bike. It’s nice and smooth to use, easy to measure, no rain… But it won’t get you anywhere.
Don’t get me wrong, I love working with a superb security person, PM, operations expert and so on! They are not wrong as people or functions. The mindset is wrong (in the specific examples I provided)! The collaboration suffers!
So, there were a lot of problem descriptions. The situations I mentioned were all wrong and yet fun to talk about, although that doesn’t help us much. I hate staying with problems, I sooo prefer solutions!!! Let’s leave the problems and move on to something useful. The interesting question is: How can we increase our chances of success in the initiatives we are working on in our daily lives?
I have collected five suggestions. They are able to help solve the sad, negative and overall destructive situations I think we have all seen out there! And, rest assured, there will be a happy Hollywood ending! :)
Let’s get started. All five suggestions address the collaborative mindset and climate. I WANT to bridge the gaps because it’s in the gaps that a lot of interesting potential lies. Let’s discuss what really matters!
First out, suggestion number one, which may be the most important of them all.
References
[DDD] Eric Evans, Domain-Driven Design. Tackling Complexity at the Heart of Software
The series published so far
<< This >>
Suggestion 1: Start with the purpose
Suggestion 2: The business and its outcome is the context
This is an adapted extract from the presentation called “What really matters” that has been presented in cities including London, Sydney, Hamburg, Frankfurt, Berlin and Cape Town.
This article was originally published on LinkedIn. Join the discussion and read more here.