Lean

agile, Brexit, CIO, Investment Management, Leadership, Lean, Lean PMO, Politics, Stability, Strategy

A Nifty Article Fifty Breakdown


No Comments

If you are a UK CIO you have a lot to think about if June 8th takes article 50 to its natural conclusion…

Here is a nifty breakdown from CIO.com..

“The major milestones for CIOs to keep an eye on include the following:

  • U.K. parliamentary review of Great Repeal Bill (Late 2017): This will provide the first opportunity for an initial assessment of legal impacts on managed service agreements and other IT contract documents.
  • Royal assent of Great Repeal Bill (Mid 2018): At this point, any gaps in the legislation should be addressed, enabling IT organizations to confirm legal impacts and initiate contractual change activities.
  • Brexit negotiations wrap up (Fall 2018): This will create clarity the regulatory, operational, audit, and reporting impacts on IT services.
  • U.K. Houses of Parliament, European Council, EU Parliament, and remaining 27-member Parliament vote on deal (Early 2019): This will confirm IT impacts and enable CIOs to begin related IT change programs
  • Transition period begins (March 2019): CIOs can structure timelines for completion of IT projects to address necessary digital transition and transformation requirements.”

http://www.cio.com/article/3189040/it-industry/how-brexit-will-impact-global-cios-and-it-services.html

However, with all these (less face it) rather boring boxes to tick and cross there will be little resource to deal with the ever increasing pace of change within the wider economy.  As such, the threat of Brexit is not just one of legal and commercial wrangling (Although that will certainly feature heavily).  The real issue is going to be that already stretched IT departments are going to be hit with “Regulation, Regulation, Regulation” when they also have to deal with “Innovation, Innovation, Innovation”.

If Brexit goes ahead the latter is likely to be the biggest casualty.

So how can the CIO keep pace with this?

During this period 3 things will be key to the post-article 50 CIO:

  1. A razor sharp focus on investment in the biggest IT return.  Yes Brexit projects will HAVE to happen but others will need to be picked for their direct impact on organisational outcomes.  This might be revenue or reputation, either way it will be high on the agenda.
  2. Use of Agile to ensure that those BAU projects are kept on track.  Agile methods and techniques such as KANBAN will be needed more than ever to keep visibility high.
  3. IT departments will need to become product centric and better at marketing than the marketing department!  No-one will use your internal product let alone your external one if your team can’t break through the noise of Brexit.

Magic Milestones has a number of services specifically designed to give you maximum bang for buck in times like these.  Read more here.. https://magicmilestones.com/services/

Leadership, Lean, Lean Startup, Product Management, Project Management, Stability, Teams

Did you just build the wrong team?


No Comments

No-one goes to work to do a bad job.

Sometimes it may feel that way but really… they aren’t!
Some people may be in the wrong job, someone may be having a bad day, they may have a completely different agenda to you but 99.9% of the time they aren’t trying to fail.
So why do technology teams so often fail? How can we be so bad at ensuring that technology teams actually succeed?
Well my team and I have been pondering this for some time. We’ve been working on something called ‘Team Genes’. Looking at the genetics of what makes a good team so that we can replicate this for our clients. This is my current stance on the subject..

If we built software like we built teams we wouldn’t be so surprised at the outcome.

Organisations consistently go about building project teams with no purpose, design or thought behind them at all and wonder if they have built the wrong team later down the line. The usual process is this:

  1. Bill says he needs an X
  2. Jill is an X
  3. Jill is available to do X (sort of)
  4. Bill meets Jill
  5. Bill and Jill get along
  6. Jill joins the team!

So imagine the same in the software process:

  1. Bill says he needs an X
  2. Acme’s product is an X
  3. The organisation already bought 20 licenses of Acme product
  4. Bill uses Acme product for an afternoon…and he likes it!
  5. Let’s roll out Acme tomorrow!

So let’s break down where Bill went wrong on the product front and then maybe we can learn how he goes wrong on the people front..

  1. Bill’s assertion that he needed an X wasn’t really challenged by anyone.  (Ring any bells?)
  2. The organisation is already familiar with a product so it decides that’s enough to be a contender.
  3. Hence, no-one goes out to look for any other options thus assuming the organisation’s first choice of product was a good one.  Note that the requirements have had a cursory glance at best.
  4. Bill’s happy so let’s go!

The dangers of choosing a software product in this way are that:

  1. An organisation repeats its mistakes time and time again
  2. Politics tend to rule over substance
  3. There is no strategic relationship built with the supplier or investigation into common values and goals.  Hence, the organisation may find the vendor giving them less value over time.

And most CIOs would laugh at Bill.  Silly Bill.  Rash Bill.  And yet the product that Bill was assessing was worth maybe, 10K a year in licenses.  (These days probably a lot less).

But the person that Bill is assessing in the first example is going to cost the business between £200 and £800+ PER DAY!! People often cost between 10 – 20 x more than software does and yet we use MORE RIGOUR in choosing the former than the latter!

Here’s where you might be thinking the following..

This doesn’t apply to my company as we always create job specs for all roles

Newsflash.  A job spec isn’t a requirement.

Do we write a product spec when we go looking for software?  Hell no! We write user requirements.  We state the problem and not the solution.  (Well most of the time anyway).  A person specification would be something like this.. “My name is Bill.  I’m a busy Product Owner with a day job and I’m currently writing all my own user stories.  It would be great if I had someone who could reduce the team’s reliance on my time by creating user stories for me.  I could then spend the time I do have with the team answering their day to day questions about business processes.”   Yes the answer might be to get a business analyst in.  Or, it might be to utilise the test team differently.  Or, it might be that the Dev team lead is totally happy to help out here.  Unfortunately, because we are so used to the status quo we leap to the solution in the blink of an eye.  This is partly because we want our problem solved and partly because in most people’s hiring process, the quickest way to get your problem solved is to ring up an agent and say,

“I want a business analyst please.  For the rest of the project. 3 months would be good and I want them ASAP please”

Let’s look at the next part of the process.  Jill is available.  So Jill is suitable.  That’s the problem with hiring ASAP.  Suddenly there’s a drought for the thing you need the most.  So we look at who is available.

Are you now throwing things at your computer?

Of course I only hire people who are available!!  Why would I do anything else?

Well this point is kind of related to the last one.

Sure someone may not be available, but that doesn’t mean they can’t help you.

Being lean is about minimising waste and waste (when applied to people) comes in the form of under-utilisation.  But how many companies truly assess this ruthlessly before going off and hiring?

Finally, let’s look at the 3rd part of Bill’s process.

He likes her.  He hires her.

Well here’s where I can totally disagree with you.   We hire people using personality assessments as well as those for competency.

Okay not bad.  What if Jill hates doing X? Wants to move away from X and you are just making her do more Xing?? We rarely find out if people are interested in roles just whether they are competent enough.She might be good at it sure but is she passionate about it?

Last but not least, Bill and Jill may not even be working together to produce the same stuff. Jill gets parachuted into a brand new team and left to fend for herself. We used to let software out of the packaging to fend for itself but we soon stopped that. We realised it was insane to impose software on people without due care and attention and yet this is exactly what we do when we impose one person on a whole group of people and vice versa.

Doesn’t that sound a little insane?

How about we do this instead?..

  1. Write a problem statement not a job spec, rather like we do for products
  2. Let the team interview the person rather than their prospective manager or someone who ‘knows’ about the area in which you are hiring
  3. Test where Jill naturally sits in a team and assess if Jill would clash with anyone else or whether there is still a gap.
  4. Ideally do an assessment of your team before you hire ANYONE.  Then you can use this information to inform your choice of both role and the type of person you need.
  5. If they are costing more than around £8K per month, try them out for an afternoon.
  6. Be prepared to accept a failure has occurred – fast – and take action if necessary.  People are rarely fired for swift action provided it’s backed up by evidence.

But that sounds a bit of a long winded process.

Really?  How many hrs did you spend interviewing people last week?  You probably did at least 3.  That’s 3 hrs of your time.  That doesn’t include anyone else’s either.   HR?  Your boss?

We think life’s too short for endless interviewing.

So.. here’s the news.  Magic Milestones can set this up in under 24hrs and it saves time beyond just the first hire.  No-one gets near us without a competency check anyhow so that bit’s done.

To be a member of the Team Genes club our people are tested all year not just when you ask for their services.

Using a different method of hiring is brave.  We know that people’s habits are hard to change.  Why don’t you start the ball rolling and find out more here.

In the meantime, I’m just going off to help Bill out of a fix..

 

 

agile, Failure, Investment Management, Lean, Project Management, Project Office, Scrum, Strategy, Uncategorized

Why do only 2.5% of companies successfully deliver 100% of their projects?


No Comments

PricewaterhouseCoopers reviewed 10,640 projects worldwide and found that only 2.5% of the companies successfully completed 100% of their projects.

Is this because people are incompetent?   It’s a sad look out for man kind if so.  However, the reality is likely more complicated..

  1.  People can’t concentrate on more than one thing at a time http://bit.ly/1etgh4B so as organisations are made up of people, that applies collectively to organisations as well.
  2. The more time we have to do something the less we achieve.  Take Kickstarter projects as just one example http://kck.st/1VjLaSi  Kickstarter changed the maximum length of a campaign from 90 days to 60 days in 2011 after realising that campaigns that ran for the full 90 days were successful only 24% of the time much less successful than shorter campaigns (over 44%).
  3. As humans we naturally radically under or over estimate what we can achieve.  Unlike pigeons(!) we use contextual information which can lead to biased judgments of interval duration, thereby reducing the precision of these estimates.  http://bit.ly/1XDbbKU

This is why at Magic Milestones we work on 3 themes:

  1. Creating a stable focused team Agile Experts
  2. Focusing on ‘the next right thing’ Lean PMO
  3. Creating a delivery culture using Lean Start-Up and Agile techniques.  Using hard data as a basis for predictions and planning we baseline performance then improve an organisation through  Consultancy & Training

Read more about why we do what we do via Our Story