Creating Business Impact

In Altnet conference, one of the discussions was around why we can’t tell business “this system is not working, we have pains with overtime and bad code”; “we should go agile” and “ship in small pieces”.
Proposing a new thing is hard for business to pick up and put into process. If they can’t see the benefit, they won’t believe us. Of course more importantly, we should believe in ourselves first.

If you are an idea person, it kills you more to have the same system/people not listening you…
If it is not working, you may listen to Fowler: “if you can’t change your organisation, change your organisation.”

However, this is my fifth company, and being confident about yourself gives the power to find a nice company in a few days/weeks; there are thousands of companies out there! Unfortunately, some of the companies did change after I have left. [Can’t they change when I was there? Should I be leaving to make a company change?]. I started to thinking that maybe I should be doing something more “effective, having more impact” for business so that they will listen, and take my offer into account. Eventually, I will feel happy and satisfied…

Just because of this reason, I was in training last week: Creating Business Impact.
It suggests a template:

1. Present Position:
[Don’t go straight into the problem. Do]
-Think about giving praise, thanks, and recognition, if appropriate
-Describe position now [e.g. sales, layout, staffing, system, equipment]

2. Problem
-Describe this so that the reader has a clear picture of what is happening, or could happen, if things don’t change.
-Stick to the facts, rather than your opinions which could differ from your reader’s.
-Don’t be too emotive -sound rational and reasonable.

3. Possibilities
– Set out different ways you could address the problem
-Number of ways. Give main advantages and disadvantages of each.
-Don’t confuse your reader with too many ideas, but you need to show you have thought beyond one solution, or one favourite brand.
-If you have a lot of facts and figures to present, put these in an appendix, and in a format that makes it easy for your reader to compare like with like.

4. Proposal
-State which possibility [or combination of possibilities] you recommend, and say why [without repeating all the advantages listed within the previous section]
-Anticipate likely objections, and address these.
-If possible, say how long it will take to get any return on expenditure.
-Say what happens next [i.e. Ask for finance, meeting].

That’s all…
Let’s see, if I can change my company this time [without leaving it]…

And Management Decides

There is a myth that at some point people starts to say that “tell business management about this.”
“But this is purely technical!”

I am not good at talking people coming from nontechnical backgrounds, and I find it quite interesting. They have eyes wide open, no idea what you are talking about; the literature you use is coming from MARS, and to take their attention and talking about the problems is not the nice part. However, when you start to talk about solutions, generally, it is a resource issue and it is hard to convince your needs/problems are really important.

From business perspective, I am sure everyone is coming with important things. And they have [hopefully well-known] priorities. They will take action based on the importance and relevance of the items.
What I can’t understand [or do understand but find it illogical] is that some companies have no roadmaps for some years. I find it harder to talk in a technology driven business that technological investment is in the very last rows of the priority list. 

In IT department, everyone is slow, not because it is UK, but they have no standards [or everyone has one].  Even the more process you create, the more slow you do your job, the more appreciation you get. If you deliver a project just to update a row for two months with three people, yes I am frustrated.

The business believes that if they continue what they are doing, they will be ok. They can be more than ok, they can be create state of art projects, but fine stick with the one we have and accept that “updating a row should take three people two months, and all a hundred documents are useful.”  UML documents are a subject for another blog, I do believe in documentation, but not modelling each call that creates a constraint for the creativity for the developer. Then don’t call him a developer but a code monkey. And if the strategy is outsourcing the overseas code monkeys, my questions are still valid that “technology driven business” [not software house] should have a core team in-house…

or not?