The behavioural impacts of Just in Time (JIT) in the Interim & Gap Management market

The inspiration for today’s thought piece is a small and medium sized enterprise (SME) and now our new definition namely MELE (Medium Enterprise to Large Enterprise) decision making styles and abilities.

Our enquiry runs along the lines of discussions and conversations we have observed in the Interim and Gap Management market.

If decision-making and more importantly the ‘pre-engagement life-cycle’ time has shrunk, is that why some Interim and Gap Managers (I&G) are extremely busy and run off their feet and others not?

Is it a pure marketing and reputation effect the busy I&G Managers are facing versus the ones ‘on the bench’ or is it because SME, MELE and to some extent large corporate clients have delayed resourcing and strategic decisions to the extent of jeopardising the normal pre-engagement fact finding life-cycle?

Finally, if JIT and agile decision-making is here to stay, will the client community still allow the I&G Manager enough time to do the really value-added stuff, which is spend enough time understanding the culture, environment and agenda of the organisation in order to help shape the changed future state?

Was Kurt Lewin wrong with his Change Management Model of ‘Unfreeze – Change – Re-Freeze’ cycle that in an agile planning and development world, there is just no more time to ‘Re-Freeze’ the changed organisational state?

theMarketSoul ©2011

3 thoughts on “The behavioural impacts of Just in Time (JIT) in the Interim & Gap Management market

  1. It’s a nice blog you have over here! It’s very usefull information for me and I just want to thank you for that! If you post more threads as this one, I’ll follow your blog active!

    Like

  2. So, we should go back to unplanned change rather than formal change instances.

    If we could guarantee the defect free quality of change, up front. Then this step is actually not needed. What exactly is in place to change the 0.60 defect rate per k Source Lines Of Code? What exactly is in place to change the 1/10 to 1/100 defects from being a n Application Security defect? What exactly is in place to reduce the impact of the damage that results from exploited coded defects, or the rate of exploitation?

    Even Microsoft Security patches can justify acceptance testing before installation. If we can make such a world, I am completely interested. But, to pretend that we live in such a world before a genuine alternative is created, as if by saying a Magic Wand exists to do it, is not the level of excellence that wins LEAN or Six Sigma a good name.

    Like

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s