Thursday 26 November 2015

There is still work here for me to do

I regularly question why I stay in my current job, when I could earn more outside the organisation.

I've come up with this answer:

There is still so much to do.

I got advice long ago that if you run away from something that needs fixing, then you're doomed to repeat the same failure in the next role.  Whilst I think that people can "start afresh", I do agree that one needs to get it right before moving on.

Wednesday 25 November 2015

Dispair, dispair - pt2

I attended a workshop yesterday.  It was quite well run, with a series of "topic based tables" that everyone circled around.  Each table was chaired by a "facilitator", a senior manager (or in some cases, 2 senior managers) who were more often than not giving output under the guise of asking questions, which is of course not facilitation.  But that's not the issue that I want to talk about.

There were a few things that really disturbed me.

Firstly, one of the issues was that users had got some money and started buying IT with it.  This didn't fit in with the IT department's plan to control IT in entirety.

I listened to this conversation for a while, which centered around "how can we stop them buying IT" and eventually I had to ask the question - "What are you not doing that's causing them to buy IT?"  So it now became a conversation about the market gap.  So these terrible, rogue users were buying IT because the IT department wasn't turning around requests quickly enough, they were too expensive, and they weren't supplying what was requested.  So, there was clearly a market gap that the users were having to fill themselves.  But instead of the IT dept saying "we should be trying to understand the customers better and respond to their needs", they were saying "how do we prevent these users buying stuff" which in my view is cutting the user's throat.

The second thing that concerned me, was the "how do we all get on the same page?" question, which was effectively suggesting that the users all should get on the same page.  Well senior managers, I'm going to tell you something.  As soon as you all get on the same page, then you'll have a better much better chance of getting the staff to do so.

To do this requires senior level consensus, the building of a shared view of the landscape - and that must happen at a senior level.  That means that you have to lock yourselves in a room and get to an agreement of what the shared picture looks like.  Then you have to share that with the teams and all work to it.  Simple, but it won't get done because you're all too focussed on how much more stuff you can scoop up.

There are also people going into positions because they're senior...but they have no idea how to do the role.  So, in this case you need guidance from SME's.  My input to this was "develop a process that you can follow, publish it, follow it and iterate".  As I say "In the absence of any other plan, my plan is the best plan".  So plan, but remember that no first plan ever survives contact with the 'enemy' (Sun Tzu).  Agile working isn't so much making it up as you go along, but more about having an approach that's good enough to begin, and then building on that over time.  But make the process repeatable and known, put the logic in there and judge things against that.  Then, change what doesn't work.

Thirdly, I heard voiced a few really terrible statements "we're going to focus user engagement on the big ticket change, not the day-to-day stuff, but then a failure to realise that the everyday stuff IS the big-ticket stuff that you should be consulting the users on.  Projects aren't the big spend that you think they are!  Your 'aspirationally' mobile, flexible workforce would tell you that they want mobile devices (they wanted that 10yrs ago) and you're still buying them desktop PC's and deskphones.  So, you'll end up buying both and lots more besides because you simply didn't bother to understand the requirement from the user perspective and that was because you were talking and not listening.

The final thing, which was actually 75% solved in the first five minutes was "first line keep closing tickets before the problem is solved" which got the question "Do you think that you may be measuring the wrong behaviour?" - so you're rewarding people based on number of tickets closed, rather a mix of customers served and satisfaction?  If you close a ticket early, that just leads to two tickets and an overall unhappier customer.  Encourage and embrace the problems, fix them properly and then close the ticket.  Think like the CCTV engineer that was on unpaid callout - "I don't want to have to come out to this twice".  So, don't close the ticket until you're sure that the job is complete.  Coupled with that, if your process is designed properly, then you'll be measuring the correct things and not things that drive the wrong behaviours.

There are still some mindsets that need to be changed ASAP.  Without that mindset change, the shape might be different, but everything couldn't be more 'same'.

Friday 20 November 2015

PMChat 20Nov15 - My answers!!

I just did my first PMChat.  I didn't want to be answering the questions myself during the chat, just focussing on what everyone else was saying, so here are my considered answers...


Q1) About you: What role do you normally carry out within projects? Are you a PM, BA, Sponsor, or something else entirely?

A1) I do a variety of roles, so I describe myself as a "PM/BA hybrid thingy", where "thingy" = internal consultant


Q2) How do you use to ensure that you have an appropriate level of top-management support for, and throughout your projects?


A2a) I check they're aware what's needed from them. If they're not keen to provide that, then I try and keep away from the project.

A2b) Then frequent comms throughout


Q3) How do you ensure that you have established appropriate success criteria for your projects?

A3) If there's a great customer and UR for the project, & customers have been consulted, it's usually clear what success looks like.


Q4) How do you ensure that there are sufficiently clear and detailed requirements and scope on your projects?


A4) I speak to the users, ask them about their work and problems. I also try and work out what their departmental business model is.


Q5) How do you ensure that you have sufficient resources and training to carry out the project?

A5) I'd try to convince managers first before a visit to the sponsor for assistance. I also prefer to train people up if possible.


Q6) What do you do if those resources just aren't there, or not made available to you?

A6) Short answer: No staff = no project!


Wednesday 7 October 2015

Despair, despair

I really do dispair sometimes.

I have a successful business which has some basic processes in place to ensure that I don't forget anything, and things get done.  It's minor project stuff, nothing that you'd do a Gantt chart for, but still important to my customers.

I occasionally help people out with Business Analysis work, charities and small businesses.  This is great practice for me and really helps them out.  It "sharpens the axe" for my day job and doesn't impact negatively on the work I do for my main employer.  In fact, it's massively enhancing to the day job, like CPD and self-funded training all rolled into one.

So, why the frustration and despair?

Simple really, my day job is working in an environment where no-one seems to produce much, and excuses for non-delivery don't even seem necessary.

Is it acceptable to cut off a service and just leave staff high and dry?  No!  "They'll just have to wait for a solution?" No!  Get a grip.  Every business model says that business is going to hell in a handcart.  Let me explain:

Porter's five forces says that you're at risk of being integrated.
Osterwalder's VPD says that another service will disrupt you, because you're not doing what the customer needs.
The list goes on, pick a model and plug in the way it works and everything points to a failure down the line.

The key to this is that the internal public sector doesn't operate like a business.  Some say that it does, but in my experience it does not.  It may aspire to do so, and it may outsource things to business, but the fact remains that you get paid for turning up and not for doing stuff.  What I'm saying is that it's basically not a performance culture.  Sure, there are performance reviews but that's really just more bureaucracy, reducing efficiency.

So, can you pilot a better approach?

Now, if you make one part a performance culture, it can't work because all the other parts aren't.  You'd just create a single failure.  You really need to reform the whole system.  Look at a small business, they get stuff done fast because they need to work, invoice and get paid to live.  I'm not saying that it needs to be 100% like that, but we need a system where people who produce nothing can't hide behind excuses.  You need to revise the system and make it more "lean", where people can raise issues and they get dealt with and when a suggestion is made, it actually gets looked at seriously.

I can't fight it much longer.  I need to find a way out of this asylum.


Thursday 24 September 2015

Car emissions and ethics

This was originally supposed to be a post about the dis-benefits of gaming the system as a car manufacturer and how there were wide-ranging impacts beyond the basic "it pollutes more, who's going to pay", but while writing, it scope-crept into a much wider piece on ethics.

VW recently gamed the vehicle emissions test, so that their vehicles recognised that they were being tested and produced more favourable results when on test.  No harm done, right?

Yeah, right.

The impact of this is massive, even beyond the initial fine that VW will be expecting.  It goes beyond VW, beyond the car industry, beyond everything to the core of our society.

This should send out a solid message to all of us - integrity is critical, not just while we're being tested, but when we're out there "in the wild".  Do we still do what we promised, and if not, what are the consequences?

Say that VW make the cars conform 100% and it makes the cars undriveable?  You bought it after a test drive, so can you get a refund?  If not, claims are bound to come along.  These cars aren't cheap, and that's quite a bit of capital that VW might have to buy back.  What if your promises don't live up to expectations?  Did you make claims at interview that you wouldn't be able to reproduce for real?  We all big ourselves up, right?

Moving back to VW, if owners accept that the performance needs to be 'as is', are they going to pay the back tax on excise duty and initial tax?  How does a prospective buyer know if the car is modded or not?  How do the people that you're working for know that you're a quality product unless you're honest and have a track record of that honesty?  We pretty much promote people based on their capability to blag (small lies), so isn't that acceptable?  Once you're caught, how can people be sure that they can trust in the future?  This is about fundamental ethics.

If you bought your VW as a company car, then will you get additional taken from your wages to cover the higher tax bracket?  Perhaps you might have chosen a different car in the first place?  This has parallels in the interview, psychometric testing and test scenarios.  Did you game the system to pass?  I know of people who did that and can't do what it 'said on their tin'.  How do we cope with that in employment?

It isn't yet known how many other manufacturers are affected, but as manufacturers share parts then it wouldn't be surprising for most of VAG to be affected.  Other manufacturers may do even worse stuff than this, but you can be sure that people are now going to be keeping a close eye on behaviour.  So how does that play out in employment?  Is it acceptable to share information on how to game interviews at your work?  Shouldn't the pass/fail be about the basics of 'will you fit in?' or 'can you do the job?'.  Ethically you should present a good view of yourself but not game the system to pass, or is it OK to do this if you're just going for a post that you want but not if you create a line of cars that break regulations?  Does scale matter?

So, before you talk about your capabilities in the future, think about how that may impact on you and your customers.  If they knew the truth, would they still choose you?  What are the consequences of your claims beyond your current role?


Tuesday 22 September 2015

A shared landscape

So, was at a presentation/workshop today and there was some talk about a transformation programme that seems to have lost it's way somewhat.

This immediately cast my mind back to a discussion that I had with one of the Programme Managers when I first worked with them.  I said "There is no senior consensus view, no shared map of the landscape" and that assessment still stands.

The problem is that if you've not discussed, debated and agreed the shared map of the landscape, then you're all operating from different maps...and that's just chaos.

So how to recover?  Well, the key is to get to a shared landscape and get everyone on the same map.  Same map, same version.  People need to agree the map is an accurate representation of the world and then move toward that goal.  I don't think that current efforts have been wasted, but we need to avoid moving further apart than we already are.

No shared view?  Well, eventually everyone will just lose interest and go off on their own.  No big group of people moving towards a common goal, but instead lots of smaller groups diluting the effort.

Lego play


I attended a Lego Serious Play (LSP) event yesterday, with the intention of finding out a little more about the system.

Lego Serious Play is a system that is endorsed by Lego, and can be used in a variety of different ways, but the overall concept is to model, visualise and communicate the business system.  This allows communication and sharing with other members of the team.

The principles of the system are quite straightforward - break the ice and then work toward a visualisation of "as is" and "to be" models.  Working alone and then coming together to make a consensus view is similar to other systems such as Business Activity Models (BAM), Soft Systems Modeling (SSM), Porter's Five Forces and others, so I felt quite comfortable with the content and that there was something solid behind it all.  This type of thing is critical to joined-up business.  I've seen many times where there are different people pulling things in different directions and the reality is that you need to have a way to bring all that out of people, get it discussed and get to a consensus.  Until that happens, then you're all running separate, competing businesses.

I love using graphics in business and I've never really understood why many businesses like to convert these graphics (which is easily understood) to a narrative (which isn't).  Businesses need to get over the whole "writing it up" thing and accept that their teams will naturally engage better with something simple and visual than something that they have to put effort into, like 70 pages of text.  Once you accept that people don't read the text, then it sets your mind free.  I'm not religious but I know the basis of the 10 Commandments whereas I don't know the text behind it.  I don't know most of the policies where I work and neither do your employees in your business.  They say that a picture is worth 1000 words and I really do believe that.

One reflection is that the Lego system allowed people to use some really weird abstract things to represent various business objects, and I felt that this then meant that the participants needed to explain the visuals more than if a car was represented by a car, for example.  I just felt that if you represent your cashflow as a leopard then it probably says very little about your cashflow unless you explain further.  Even your own organisation might not understand the "cashflow as a tiger/tree" concept without more narrative, but then maybe that's the point - you have to get people talking about their perspective and listening to the perspectives of others before you can develop a fully-formed model.

I've seen the phrase "permission to play with xxxxxx" used in these types of events, and I can imagine that there are some businesses where this approach would work well, and others where it wouldn't.  I'd love to get a C-suite playing with Lego for a day and see their reactions.  I've rarely seen anyone not pick up some Lego and make a little something or other, so I imagine that it would work better than you might think.

Would I use the system fully?  Perhaps.  I've got some icebreakers that use Lego and people genuinely engage with those tasks in a way that I've not seen with silly questions, who you'd throw out of a balloon, etc.  So, I think I'll be giving it a try and seeing if I can use it further before I become a LSP practitioner.

Dave @jugglingsand

Wednesday 12 August 2015

Lessons not learned

We don't learn lessons in projects.

Why not?  According to Jason Fried (21 Signals) the organisation learning of how we got somewhere is important to know just why we did what we did, bit also the mistakes we made and the things we learned on the way.

So, if we're looking to develop a new thing, it's important that we understand what worked, what didn't and why.  That way we can inform other work in the organisation, so they gain the benefit of our experience.

But we don't learn, because there's no appetite to do that.  People say "let's move on, let's not focus on failure", but sharing that failure is critical or the learning is limited.

I'm not overly keen on getting criticism, but I accept that it has to happen in order to improve.  Someone who says that you're great all the time isn't helping you grow in the longer term.

So, if something went well, let's hear the feedback of how it could have gone better and if it failed completely, let's hear why that happened too.  Don't just sweep it under the carpet! 

Thursday 6 August 2015

Using the phone on the train

I have no idea why people use their phone on the train for voice calls.  The signal is just too flaky.

Consider this conversation:

"Hi there...I'm on the train...yes, yes I just wanted to let you know in case we get cut off...you know how people do...hello? Hello?"

Dials again

"Yes, I know, terrible isn't it...you can never have a full conversation, can you?  Uh huh, the signal is a bit dodgy...pardon? Hello? Hello?"

It went on like that for about 10 minutes, and absolutely no information was transferred apart from how bad phones are when used at 120mph inside a big metal can.

The worst one of these calls (and the reason why I no longer use my phone for voice calls on the train) was when my boss called me for a chat and we both were on the train at the same time.  I don't think we managed any more than 5-10 seconds of connection.  In the end I just turned my phone off so the call making/breaking couldn't continue.

Relax and watch the world go by, work, read, whatever...but just don't try and call anyone.  Use texts or e-mail to communicate and enjoy that your messages will be received gratefully by the other end knowing that they didn't have to try and maintain polite conversation about how phones don't work very well on trains.

Thursday 25 June 2015

Games playing and the 'non-available manager'

I've seen people playing politics in business and I rarely like it.  As a PM I see this all the time and although I accept that's how people often do business, it seems to me that it's much more destructive than helpful.

It always reminds me of the opening comments from one of my project management lecturers:

Him: (to class) "Hands up if you don't like politics"

(People gingerly put up their hands, not knowing if they should or not.)

Him: "If you've got your hand up, don't become a project manager."

I don't fully agree with this.  I don't like politics, but I make a reasonably good BA and PM.  I think that you need to be aware of politics, but you shouldn't get involved...if possible.  You should also discourage it in others.

There is a simple truth here.  People don't play politics all that well, but they think that they do.  Funnily, we're just older versions of the kids in the playground - sulky, bullying, stopping other kids having the toys - often just because it's possible to do that.  Is that you?

The worst part is that the BA/PM is you best ally in getting your business change delivered, but you constantly get fobbed off.  Why you'd go to the trouble of asking for something and then stopping it happening; or denying access to assets, people or knowledge; or refusing time to define the deliverables, just seems so odd to me.  You're paying for me, and the quicker things happen, the less you pay (or the more I can do).

If you don't know what you want, (and I suspect that's what the issues often are) then just admit that and I'll deliver that you do know as a agile prototype and not a "big bang" rollout.  Saying that you don't know often sets you free.

There are still some serious game players.  I've pretty much seen them boasting about this.  If you're one of those people, then please consider this:

"If you're playing games in business, you probably think you're some sort of strategic genius.  No, you're just confusing everyone and wasting cash." (@jugglingsand)

Honestly, I really don't mind travelling somewhere in order for you to cancel meetings or not show up, but you're going to have to do the meeting at some point, with me or someone else and you're costing the organisation a shed-load of cash for every second of my time that you waste.  Where there are benefits that justify your project, you're diminishing those too.

So, you can dismiss my 'big paper', 'sitting around on bean bags, debating solutions' approach as 'new age', but bear with me and I'll help you understand the changes needed, nail down the spec and reduce the chance of failure later on.  If not, just keep playing the games and watch as you take the flak for non-delivery.  Your move.

Wednesday 24 June 2015

The "Market Gap Effect"

I was invited to a meeting as a guest the other day, where some senior staff were discussing an issue they were having.  My purpose there was to give an update on some project work I was helping them out with.

Manager #1 - "Organisation X is trying to muscle in on something that we've always done.  That can't be right, it was always said that the key difference between Org X and us was that we did this thing and they didn't."

Manager #2 - "Yeah, someone ought to stop them doing that.  That's our remit."

I sat there, wondering at what point was best to interject.  After all, I was only an guest.  Finally I felt that I needed to speak.

Me - "So, are you saying that they're disrupting your business?  Trying to takeover your remit?"

Manager #1 - "Well, no...we stopped doing that thing some time ago."

Me - "I think that it's really important that you look at your business model here, after all, that's what defines what you do and how you do it.  E.g If you're a local village grocer's shop you probably shouldn't suddenly change to selling sporting goods and stop selling food.  If you've pulled the plug on something that you supply which they need, then you can't really blame them for filling that gap themselves."

There was a stunned silence as everyone looked from one to the other.  Did they understand me?  Were they going to kick me out?  I stared back at them.

Chair - "I think we'd better start doing that thing again"

Phew.

I realised that I'd just stumbled on a practical example of what I call "The Market Gap Effect".  It's nothing particularly complicated really, it's just that if you're doing something well, and customers like what you do, then if you stop doing it, you're going to leave a gap in the market.  The effect of leaving this gap is that someone else will fill it with their offering and take a profit from doing it.  Not only that, but you alienate your customers because you've cut off something that they need.

Now you may ask why they'd stopped doing a key activity, one that people were happy with and needed them to do.  I'm not really 100% sure, but in my travels through business, I've often found that many organisations either don't plan their changes very well, or they just feel that a certain area of the market isn't where they "should" be operating.

In the case of business change, they know where they want to go, and they're so focussed on that, they forget some key things that they were doing well in the past and eventually the people doing those things forget to do them too.

Where there's a need and the organisation feels that it no longer wants to operate in that area, then that's a prime case for selling, outsourcing, sub-contracting or whatever you feel is most practical.  You can't really just stop doing it, because your business has value wherever it does something that someone else needs or is prepared to pay for.  By just stopping doing that thing, you're giving the value away to whoever spots that the need is there and is prepared to service it.

So, beware of "The Market Gap Effect" because those people who buy things from you will need to go elsewhere if you don't supply.  I'd be glad to hear your comments on if you've seen this happen in other organisations where you've been.  No names needed.

#marketgapeffect
@jugglingsand

Saturday 18 April 2015

Project failure, a sermon

I'm writing this because @SusanneMadsen suggested that I should do it.  Susanne was talking on Twitter about why do projects continue to fail and what can we do about it?

I wrote my masters dissertation on project success, taking that success was the opposite of failure and post Chaos and others we seem to be pretty clued up about how projects fail.

So, Susanne posted and I responded with the following reasons:
  • ·       People and politics
  • ·       Rushing into delivery
  • ·       Lack of need
  • ·       Poor requirements
  • ·       Delivering a thing and not change itself

I will attempt to break these down further in the next few paragraphs.

This post is not a reflection of my masters research, or an in-depth response, but more about what I feel are some of the reasons why projects fail right now.


People and politics

People are necessary for projects to succeed.  They are also a major reason for failure.  When we embark on a project, we should only do so after having engaged with stakeholders. So, if you're engaging with stakeholders, nothing can go wrong, right? Actually, yes.  People in business are often like little warring tribes, all trying to score points off each other, battling out and messing each other around.  As the BA/PM you walk into all that and stir it up. So, people will sometimes misinform you, feed you false information and generally make nuisances of themselves.  They'll use control of resources at their command to pull the rug out from under you, tell tales to try and get projects stopped and generally just cause absolute mayhem.  In this respect, being a PM is sometimes an absolute nightmare. The only thing that I think you can truly do to ensure that this doesn't happen, is to change in such a logical way that no-one can really dispute it.  You have to have a really robust argument and be able to explain it fully.  You also have to communicate constantly throughout the change. People will always create waves (NIH, etc) but you can try and do things to reduce the effectiveness of their undermining.


Rushing into delivery

Often, once someone has "sold" the idea of the project to someone senior, it'll be a mad scramble to get on with things and show movement. It's at this point that we need to just pause and take a breath.

Sure, the idea is great...but should we really do it? We need to thoroughly investigate what we're doing and plan it properly. Only then should we get on with it.

I recently saw a pretty reasonable sized effort that had been wheelspinning for around 12 months for this very reason. People were just getting on with doing "stuff" that they thought would contribute, but really they were getting on with a number of disparate legacy stuff that aligned vaguely with where they thought it should go.

12 months on, and everything is only now starting to actually gain traction and move forward.

So, you might say "yeah, sure but at least they were moving forward". Indeed, but there was little link between things, and that meant that they were potentially investing without much thought. Benefits, benefits, benefits. Look at how things need to change structurally, then move things to suit. Don't just say "we need a new time management system", because you can probably do what you need with the old one and if you've not thought about what you're doing, then the new system probably won't be right either.

So you'll deliver on time and in cost, but it'll be the wrong thing and therefore you'll have 100% failed.


Lack of need

Often, people just buy and upgrade things without thinking "Do we need this?" We need to develop systems thinking.  Do we sweat the asset that we already have?  What benefits does upgrade bring?  Why are we changing?

Perhaps it all seems like I'd rather stay the same, with my bakelite TV, pipe and slippers.  No way, change can't happen fast enough for me...but it has to be the right change.  We can't just invest in things wildly, spray and pray.

We need to think what we need to be doing and ensure that we hang investment off that.


Poor requirements

The problem with this is often that stakeholders don't know what they want.  But why should they?  In my Business Analysis work, I ask people to talk about what they do and try to improve how they do things, then within that looking at how they interact with technology.  This is not shoehorning them into a solution - often it's about prototyping and getting them to work with simple systems to "mock up" an interim solution.  During that journey, they become a better, more informed customer for a final solution.

The other thing that has become evident is that the more you think about how to streamline things and mock up prototypes, the more that people start to get why we're trying to change things. They start to engage and get involved. The change that is finally implemented is much more successful because people have thought about it in depth.

So, rush ahead at your peril.


Delivering a thing and not change itself

Here, have some ICT.

6 months down the line, "why aren't you working better?".

Well, that new ICT didn't come with any training and you didn't explain why you needed us to use it, so it's over there in the corner under the pile of coats. We have some great video conference equipment.  The quality is fantastic.  But it doesn't deliver the benefits.

Why?  Well, in order to reduce travel, you have to cut out lots of travelling.  But video conferencing only cuts out about 5 meetings a day for the whole organisation.  Everyone else still has to travel.

Culturally, most people like to go and see the person that they're talking to, buy them a coffee and perhaps they also get chance to see some other colleagues for a catch up while they're there.  So video conferencing works for a small number of staff per day, but not the vast majority.  So, small benefits realisation.

If there had been some number crunching, you'd work out that having meetings slightly later in the day would save more money than anything else.  Also, giving people a connected laptop allows them to pull up the relevant info during the meeting and therefore have less meetings.

So, look at the change itself.  What do you need to achieve?  Plan the delivery to include training, staffing, communication and handover (with suitable service levels).  Then keep revisiting things post delivery to ensure that it's all getting used as planned.


So, with all that in mind, it's not really surprising that we don't have the success that we crave.