tag:blogger.com,1999:blog-45140038794432859212024-02-03T00:38:12.184+00:00ALLYGILL.CO.UKBusiness and Software Process Management Made EasierAlly Gillhttp://www.blogger.com/profile/08266980121207923495noreply@blogger.comBlogger97125tag:blogger.com,1999:blog-4514003879443285921.post-81444836898675183602022-06-13T10:53:00.003+01:002022-06-13T10:53:56.276+01:00Stop with the Journey Metaphor - Use Your Imagination!<p>Oh, for goodness sake, please stop talking about everything as a journey. Are there no other metaphors available to us? It would seem that the business world is nothing more than a series of journeys, and all the directions are on nicely linear roadmaps. </p><p>A journey is an "act of travelling from one place to another". It says nothing about the experiences, difficulties, people, customs or opportunities that we encounter on the way. It is bland and boring. A bit like a "roadmap" ... which tells us that everything will be delivered in due course - even when we are fully aware that our requirements and needs change over time (and usually faster than anyone is prepared for)!</p><table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto;"><tbody><tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgq_ESlCwH5PfBm5-ujAJEA2C0N7m2wLgT95YH0J1qCB1OCaQg9gLwfEnOUqy5Y4zD7atwgV_lD0L-zgtiM9t0E-DJBPNOFWJupYJoMgXn-4dysIUSII-AqkLV-JQinTd7LcB57XEvkgcTTm55PpbfiUbwE_GqlEZaDkJITuFSh0t4_-77xE3shtqZ-TQ/s5307/marek-piwnicki-pvsCx35Vf3g-unsplash.jpg" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" data-original-height="3317" data-original-width="5307" height="250" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgq_ESlCwH5PfBm5-ujAJEA2C0N7m2wLgT95YH0J1qCB1OCaQg9gLwfEnOUqy5Y4zD7atwgV_lD0L-zgtiM9t0E-DJBPNOFWJupYJoMgXn-4dysIUSII-AqkLV-JQinTd7LcB57XEvkgcTTm55PpbfiUbwE_GqlEZaDkJITuFSh0t4_-77xE3shtqZ-TQ/w400-h250/marek-piwnicki-pvsCx35Vf3g-unsplash.jpg" width="400" /></a></td></tr><tr><td class="tr-caption" style="text-align: center;">Photo by <a href="https://unsplash.com/@marekpiwnicki?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText">Marek Piwnicki</a> on <a href="https://unsplash.com/s/photos/jouney?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText">Unsplash</a></td></tr></tbody></table><p>Not only are these two ubiquitous business metaphors lacking in imagination and creativity, but they are also fundamentally misleading and oversimplifications. For example, many of the real journeys we make result in us ending up in exactly the same place we started, which is pretty certainly not the outcome you want from an organisational transformation. </p><p>The equally over-used mountain climbing metaphor for learning suggests that there are numerous obstacles to be overcome until you reach the peak of your learning experience - after which there is no more learning to be done, and it’s all downhill from there.</p><p>Here’s a short list of some alternative metaphors you could try:</p><p></p><ul style="text-align: left;"><li>A Bucking Bronco Ride</li><li>An Interweb of Events</li><li>A Doctor Who Adventure</li><li>A Chemistry Experiment - Mixing It Up</li><li>A Discovery Process</li><li>Joining the Dots</li><li>A Night on The Tiles</li></ul><p></p><p>Feel free to use any of these if they catch your fancy - or maybe you could give me some of your personal favourites?</p><p><br /></p><p><br /></p><p><br /></p>Ally Gillhttp://www.blogger.com/profile/08266980121207923495noreply@blogger.com0Prague, Czechia50.0755381 14.437800521.765304263821157 -20.7184495 78.385771936178855 49.5940505tag:blogger.com,1999:blog-4514003879443285921.post-77588808914397328842022-03-30T12:59:00.003+01:002022-03-30T12:59:51.675+01:00Take Your Time and Avoid These Rookie Management Mistakes<p>Congratulations on your new promotion. It feels good, doesn’t it? Maybe a little bit scary at the same time, but you’ve got a new team, new responsibilities and probably a new working environment and other senior colleagues who you want to impress. So, you may think you can plough ahead and stamp your mark and your brand on the situation and make an amazing name for yourself.</p><p><br /></p><table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto;"><tbody><tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj7Rn-fUP2LjFRFuJBztf4-KeD-gvHtog34Q4ihfEHtwY_dxfGI7smZ5OTSn8CVb-57tZinQUeMY-5efakNK-N--xCg7q-DFfG1cj3gZCAKdjVFcKzYu2sBatvXi9JjkUCQlliLdYn4DPOVKezQo1GjwRmhLtB6c5FAB6X5iaprcrvbOvH9oEfHrjnRpA/s5184/brett-jordan-4Rvi7ybXmGo-unsplash.jpg" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" data-original-height="3888" data-original-width="5184" height="300" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj7Rn-fUP2LjFRFuJBztf4-KeD-gvHtog34Q4ihfEHtwY_dxfGI7smZ5OTSn8CVb-57tZinQUeMY-5efakNK-N--xCg7q-DFfG1cj3gZCAKdjVFcKzYu2sBatvXi9JjkUCQlliLdYn4DPOVKezQo1GjwRmhLtB6c5FAB6X5iaprcrvbOvH9oEfHrjnRpA/w400-h300/brett-jordan-4Rvi7ybXmGo-unsplash.jpg" width="400" /></a></td></tr><tr><td class="tr-caption" style="text-align: center;">Photo by <a href="https://unsplash.com/@brett_jordan?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText">Brett Jordan</a> on <a href="https://unsplash.com/s/photos/listen-more?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText">Unsplash</a></td></tr></tbody></table><p>But before you jump in with both feet, and with your eyes tightly shut, step back and have a think about the situation. Because the worst thing you can do is to start to try and mould your new team into what you think you want them to be. Here are three easy mistakes to make which may come back to haunt you faster than you may think.</p><h4 style="text-align: left;">Fixing what isn’t broken</h4><blockquote style="border: none; margin: 0px 0px 0px 40px; padding: 0px; text-align: left;"></blockquote>If you’re inheriting a team, especially one that’s been working together for any length of time, they will probably have a way of working together that has been developed over a period of time. They will know each other's strengths and weaknesses better than you, and probably better than your predecessor.<br /><blockquote style="border: none; margin: 0px 0px 0px 40px; padding: 0px; text-align: left;"></blockquote><br /><blockquote style="border: none; margin: 0px 0px 0px 40px; padding: 0px; text-align: left;"></blockquote>By all means, explain your values and high-level expectations of how you hope you can operate together, but don’t start laying down the law until you’ve got a good idea of the team dynamics, the way they work and how they achieve what’s asked of them. They may be doing great things that you’ve never heard of and it would be a mistake to throw that away simply because you work differently. You need to adapt to them as much as they need to adapt to you. What worked for you in a previous team may well be at odds with how things are done in the new environment and with a different set of individuals.<br /><blockquote style="border: none; margin: 0px 0px 0px 40px; padding: 0px; text-align: left;"></blockquote><br /><blockquote style="border: none; margin: 0px 0px 0px 40px; padding: 0px; text-align: left;"></blockquote>Don’t upset members of your team by reassigning them or changing their roles in the first few weeks. Make sure you have a full understanding of what each and every team member is currently working on. There are probably good reasons for their current assignments especially if they have a history of self-organisation.<br /><blockquote style="border: none; margin: 0px 0px 0px 40px; padding: 0px; text-align: left;"></blockquote><br /><blockquote style="border: none; margin: 0px 0px 0px 40px; padding: 0px; text-align: left;"></blockquote><h4 style="text-align: left;">Focusing on yourself not your team</h4><blockquote style="border: none; margin: 0px 0px 0px 40px; padding: 0px; text-align: left;"></blockquote>Of course, you want to impress your new colleagues just as they are going to want to impress you, but introducing yourself and your achievements in your previous role(s) should be a gradual process as part of the forming, storming, norming, performing cycle. Spend your first few days or weeks getting to know the individuals in the team if you don’t already. Use one to one meetings and team meetings and listen more than you speak. You need to understand their roles, skills, needs and desires and learn how to harness these for a common good.<br /><blockquote style="border: none; margin: 0px 0px 0px 40px; padding: 0px; text-align: left;"></blockquote><br /><blockquote style="border: none; margin: 0px 0px 0px 40px; padding: 0px; text-align: left;"></blockquote>Telling your new team how much you’ve achieved in your career and how wonderful you are might impress them, but it’s more likely to come across as arrogance and send the wrong messages from the outset.<br /><blockquote style="border: none; margin: 0px 0px 0px 40px; padding: 0px; text-align: left;"></blockquote><br /><blockquote style="border: none; margin: 0px 0px 0px 40px; padding: 0px; text-align: left;"></blockquote>Contrary to what you may think, your primary role is to support your team not the other way around. It may be your name in the organisation chart and you may be the one who is held accountable, but the team is not there to make you look good. Their role is to do what is demanded by the needs of the wider organisation or customer. If you happen to look good because of them, that’s a bonus, not a right.<br /><blockquote style="border: none; margin: 0px 0px 0px 40px; padding: 0px; text-align: left;"></blockquote><br /><blockquote style="border: none; margin: 0px 0px 0px 40px; padding: 0px; text-align: left;"></blockquote><h4 style="text-align: left;">Trying to figure it out without asking</h4><blockquote style="border: none; margin: 0px 0px 0px 40px; padding: 0px; text-align: left;"></blockquote>There’s often a tendency to think that you’re the smartest person in the room. That’s why you got the job!<br /><blockquote style="border: none; margin: 0px 0px 0px 40px; padding: 0px; text-align: left;"></blockquote><br /><blockquote style="border: none; margin: 0px 0px 0px 40px; padding: 0px; text-align: left;"></blockquote>Unless you’ve been promoted from within the team, you’re probably going to have a lot to learn, and probably in a very short time. Sure, you can do it on your own, but talking to and listening to your new colleagues will make the task a lot easier and a lot quicker. The only thing to watch out for is that you don’t get caught up with their in-built bias and to watch out for hidden agendas. One to ones will get you a long way, but use team sessions to get different perspectives.<br /><blockquote style="border: none; margin: 0px 0px 0px 40px; padding: 0px; text-align: left;"></blockquote><br /><blockquote style="border: none; margin: 0px 0px 0px 40px; padding: 0px; text-align: left;"></blockquote>You should garner as much information from within your team before you start asking people outside, especially from other managers. The people who are closest to the work will have the most honest assessment of what’s going well and what’s going badly - and the picture they paint collectively will be far more valuable than the pictures painted by outsiders and especially other leaders who may be looking through rose-coloured glasses.<div><br /><div><blockquote><br />Coming together is a beginning. Keeping together is progress. Working together is success (Henry Ford)</blockquote><div></div><blockquote style="border: none; margin: 0px 0px 0px 40px; padding: 0px; text-align: left;"></blockquote><h4 style="text-align: left;">Conclusion</h4><div>Teams often get quite excited when they get a new manager or leader. But they will have concerns at the same time and the worst thing you can do is lose their support because you’ve pushed your way in and steamrollered over their hopes and aspirations. This is especially true of mature teams and upsetting or demotivating a team with a proven track record is not going to do anyone any favours. <p>If you play things right, you’ll have plenty of time to work with your team to reach even higher levels. Or you bluster your way through and destroy a good team in weeks…it’s your choice!</p></div></div></div>Ally Gillhttp://www.blogger.com/profile/08266980121207923495noreply@blogger.com0Prague, Czechia50.0755381 14.437800521.765304263821157 -20.7184495 78.385771936178855 49.5940505tag:blogger.com,1999:blog-4514003879443285921.post-69666812775603076832022-02-15T10:49:00.001+00:002022-02-15T10:49:44.030+00:00Degrees of Trust - Building Relationships<p>There seems to be a lot of talk on the interweb these days regarding Trust. Or more specifically about trust as a necessary precursor to effective leadership. I’m going to focus on business leadership here as there seems to be an almost global mistrust of political leaders regardless of who they are, where in the world they are, or what part of the political spectrum persuasion they fall into.</p><p>As is so often the case with popular soundbites on the internet, people write statements about trust to generate likes or dislikes, and more often than not use the medium to simply reiterate other peoples’ thoughts but rarely offer any genuine insight. More concerning is that people often see things as binary conditions. Either there is trust in leadership or there is not. This idea of trust in leadership becomes vaguer if we consider that most people don’t have any genuine relationship with their corporate leaders. How many people have sat down for lunch with their CEO and talked about their worlds outside the workplace? Does anyone in the leadership team (above your departmental leadership team) know your name? How can you trust someone you don’t know?</p><p>This got me thinking that because of the richness of our language (a quick search found over a hundred synonyms for trust) we were missing an opportunity to think about trust as more than a simple positive or negative condition. Perhaps we should be thinking more about degrees of trust. I was encouraged by a discussion about the subject with a new connection on LinkedIn and further by a Twitter post from <a href="https://twitter.com/NielsPflaeging" rel="nofollow" target="_blank">Niels Pflaeging</a> who suggested that we ‘overvalue trust and undervalue confidence in people; the former cannot emerge without the foundation of the latter’ (paraphrased).</p><p>It seems quite appropriate on this Valentine’s day to step back and think about how a relationship evolves. Our romantic relationships and our business and social relationships all follow a similar pattern, and all are generally looking for a similar positive outcome. The physical manifestation of that outcome might be different but we do tend to use similar terminology - we speak of “being in bed with our business partners” or how a successful merger or acquisition is likened to a “marriage made in heaven”. </p><p>All our attempts at building relationships start with uncertainty. We start to engage in a courtship ritual in which our dance takes us through awareness, mutual encouragement, confidence, dependability, respect, trust and ultimately end with a mutual commitment which we hope will be sustained over time. I have visualised this below but you could (should!) choose your own model if you feel it's something worth taking further.</p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/a/AVvXsEjwe10b1EX_B8gxel9N2FYik-dkrkzrIml3RdXWuT_0lYIfxD4QuZuKTdeuGrCIcLWFQ0-BiEG_A1FepYiYUniMix92vZREpb5EnWec5tqNwevHvg6jeN5_Zkv2Ui8-y6LWFokWazl1WYfr6ocCo9hSfBQKCvXy_9SXXJh6o8q37onek6nQEY0eTIY0RQ=s3675" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="2016" data-original-width="3675" height="220" src="https://blogger.googleusercontent.com/img/a/AVvXsEjwe10b1EX_B8gxel9N2FYik-dkrkzrIml3RdXWuT_0lYIfxD4QuZuKTdeuGrCIcLWFQ0-BiEG_A1FepYiYUniMix92vZREpb5EnWec5tqNwevHvg6jeN5_Zkv2Ui8-y6LWFokWazl1WYfr6ocCo9hSfBQKCvXy_9SXXJh6o8q37onek6nQEY0eTIY0RQ=w400-h220" width="400" /></a></div><div class="separator" style="clear: both; text-align: center;">Background Photo by <a href="https://unsplash.com/@markinzone?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText">Mark Tryapichnikov</a> on <a href="https://unsplash.com/s/photos/ladder?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText">Unsplash</a></div><p>Sadly, as we all know, we are vulnerable throughout this engagement and at any stage, one or more parties can destabilise the relationship, regardless of how advanced or well-established. Sometimes this is just a hiccup caused by a misunderstanding, an error of judgement or even a simple mistake and the damage can be fairly easily repaired. If the misdemeanour is intentional or simply doesn’t fit with the wounded party’s moral compass it may take much more effort or it may be beyond fixing.</p><p>Relationships need to be worked on, even after they are built on strong foundations. We should never take them for granted. As we move from uncertainty to being able to make commitments we are more likely to be able to meet each other's needs - arguably the ultimate goal in any relationship. </p><p>We also need to stop taking words for granted. It's easy to read a meme on a social media site and share it, but it's far more valuable to think a bit further and decide whether there is any real depth to the phrase and whether it has any value. Like a plan, the plan itself may have little value if conditions change so fast as to make it worthless, but the act of planning gives you insight into far more and leaves you in a better place than where you started.</p><div><br /></div>Ally Gillhttp://www.blogger.com/profile/08266980121207923495noreply@blogger.com0tag:blogger.com,1999:blog-4514003879443285921.post-37372126220289004622022-02-03T11:17:00.003+00:002022-02-03T11:17:39.223+00:00I'm Not An Agile Coach - And Nor Is My Wife<p>As human beings, we have been putting labels on objects, ideas, concepts, and even people since the earliest days of language and shared communications. It helps us make sense of the world and for thousands of years, it has served us well, especially for tangible things. Putting things into categories narrows down the universal experience into something more manageable, so we can easily understand how to differentiate between say, a car and an aeroplane without having to go into details. </p><p><br /></p><p>It becomes more complicated when we start to talk about intangibles and become involved in the world of adjectives. So we can (mostly) comprehend the world of colours and distinguish between blue and red. We can largely distinguish sounds like a bang and toot. But as soon as we move to the next level we begin to lose some of that shared understanding. Blood red or navy blue become more subjective and relative terms make it even more difficult as we interpret more descriptive terms like loudness or tone. </p><p><br /></p><p>As language evolves we start reusing words rather than finding new ones and our understanding becomes even more dependent on context. Nowhere is this more prevalent than in the business world, and arguably IT is the worst culprit of all. We have to work even harder to understand what’s being discussed when even the context doesn’t give us much help. Agile and Lean are great examples of how terms not only depend on context but on organisational culture and even the person using them.</p><p><br /></p><p>As global communication expands exponentially and billions of individuals are trying to carve out a niche for themselves, the labels we use to describe ourselves and the labels organisations bestow on us become less and less useful. The distinctions between someone’s job title, their role, their job description and what they actually do have never been so blurred. And it’s not helping anyone - and recruiters wonder why CVs get longer and longer and the number of people applying for certain jobs gets bigger and bigger whilst the time needed to find the right person expands at a similar rate.</p><p><br /></p><p>For the last three years, I’ve been on a contract in Prague and the role I applied for was PMO Assistant. Internally, I believe the role was advertised as a Service Excellence Manager. In my day to day activities, I acted as the deputy team lead, communications expert, change manager, agile coach, process improvement specialist, HR admin, initiative leader, reporting expert, facilitator, trainer, train the trainer, event coordinator, proofreader, MS-Teams expert, Miro designer, and whatever else needed doing! I didn’t ever do any substantial PMO work (but I had a lot of fun!)</p><p><br /></p><table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto;"><tbody><tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/a/AVvXsEhfZZLOLcc8gL3cWbkQBI66cwwn5hoUKWhklfTtR_MYAKgYS4gBoKPhtdbWzOqFz5nstBQj4FZnlfymKAdRbyp_8RW_2I9DjPcCcAAAPJmTrhp1g_LP32mKme0v4hAgoSLEn1oShMzPP18X2_iWEBx2wQZVfMLEM1ZBktGN6H97rGsqtmtJphV0VpjUig=s4394" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" data-original-height="3299" data-original-width="4394" height="300" src="https://blogger.googleusercontent.com/img/a/AVvXsEhfZZLOLcc8gL3cWbkQBI66cwwn5hoUKWhklfTtR_MYAKgYS4gBoKPhtdbWzOqFz5nstBQj4FZnlfymKAdRbyp_8RW_2I9DjPcCcAAAPJmTrhp1g_LP32mKme0v4hAgoSLEn1oShMzPP18X2_iWEBx2wQZVfMLEM1ZBktGN6H97rGsqtmtJphV0VpjUig=w400-h300" width="400" /></a></td></tr><tr><td class="tr-caption" style="text-align: center;">I'll be the Wingman for you and your team*</td></tr></tbody></table><p>I mentioned in that list that I acted as an agile coach. But I don’t want to be an ‘agile coach’. I don’t want or need to be placed in that pigeonhole. The doesn’t accurately describe me, what I do, or how I can genuinely add value to an organisation that might make use of my services and skills. It pitches me as one person in an ever-increasing pool of people called agile coaches who range from highly experienced coaches with a vast understanding of organisations, teams, software development, business management and people to those who have joined a week-long Scrum course and got a certificate. </p><p><br /></p><p>The label doesn’t help a recruiter or a hiring manager who won’t necessarily understand the details of why they need an ‘agile coach’ other than to tick some boxes, and the job description that is posted is probably made up from a composite of what they think an agile coach should be doing rather than aligning to the specific context of the need. Once the corporate ‘agile coach’ job description has been word-smithed and stamped with HRs approval, the expectation of what that person needs to do is often set in stone and their room for manoeuvre becomes limited and the value they can add decreases.</p><p><br /></p><p>We spend far too much time worrying about this kind of label and trying to explain to others what we are and what we aren’t. Over a 40 year career, I’ve developed a lot of general and specialised skills - a veritable jack-of-all-trades and a master of quite a lot of them. Try putting that as your current role on a CV and see how far it’ll get you! But as retirement looms, it’s one less thing that I have to worry about! </p><p><br /></p><p>Right now, I’m content to be a Wingman. I’ll help you think about how you and your team can perform better in order to meet their needs, your needs and your stakeholder needs, using all the knowledge, skills and experience I’ve garnered over the years (which all have their own useless and meaningless labels!)</p><p><br /></p><p>* Photo by <a href="https://unsplash.com/@iamjiroe?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText">Jiroe</a> on <a href="https://unsplash.com/s/photos/wing-man?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText">Unsplash</a></p><div><br /></div>Ally Gillhttp://www.blogger.com/profile/08266980121207923495noreply@blogger.com0tag:blogger.com,1999:blog-4514003879443285921.post-88172093608084490292019-04-22T10:48:00.001+01:002019-04-22T10:48:09.610+01:00Using Agile Development Concepts to Help Manage Organisational Change (Part 2)<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiNQPAePBvd7rZikjwZURWQmR9bT-4M0Qi4TYBN3UW2-UJoBr0G7pL9xopL8qEy1DDafS790mQInYwnLgKJ9LxD0KuFuWJXYHYQzhcKF3SA_dzhnH-oM8mSWUgosNe4UqK1UCTYRXqUF1UU/s1600/adults-brainstorming-desk-1595385.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"></a></div>
Whilst incremental and iterative development underpin Agile Development, and Whiteboards and Stand-up meetings are often seen as the public face of Agile, there are plenty of other ideas that we can bring into Organisational Change Management to help us do things better.<br />
<div class="separator" style="clear: both; text-align: center;">
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgPMdBxtIqNu33bjsKag_4RTwPwG6udUkiVJ2IVgsvM9to1jalY7QOKKpxFj1T7ZmV1rz4dTk1-Bnb-0p0Uw-b0KXnBxbWfqyKdvCKTpaXOsf9hCLSdXGqmo7tRQNA_kEeNEIdXtXQN_Fl5/s1600/battle-board-game-castle-277124.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="1065" data-original-width="1600" height="213" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgPMdBxtIqNu33bjsKag_4RTwPwG6udUkiVJ2IVgsvM9to1jalY7QOKKpxFj1T7ZmV1rz4dTk1-Bnb-0p0Uw-b0KXnBxbWfqyKdvCKTpaXOsf9hCLSdXGqmo7tRQNA_kEeNEIdXtXQN_Fl5/s320/battle-board-game-castle-277124.jpg" width="320" /></a></div>
<br />
But just before I get into the details, I want to make a clarification. This set of articles is built around the premise that there is no such thing as Agile Change Management. I recently attended a Agile Change webinar organised by the ACMP and the guest speaker was Tim Creasey from Prosci. I’ve had a lot of support from Tim in respect of these articles, so I was intrigued by his take on the matter. He talked a lot of sense, and from my perspective, we appear quite closely aligned in our views. But one idea he emphasis really stood out for me. This is my interpretation...<br />
<br />
There is Agile and there is agile. If you’re talking Agile, you’re either talking about the Agile Manifesto and Agile Software Development. If you’re talking agile, then you are looking at ways of being flexible, being nimble, quick, spry, sleek, ... go find a Thesaurus and find the words that best suit what you want to be! Just be clear about whether you mean uppercase or lowercase agile. There is a huge difference!<br />
<br />
For clarity in future I shall be as precise as this. When I’m talking about Agile Development, I shall use the capitalised noun. Anything else if referring to the concept of being able to things better in general.<br />
<br />
In this post, I want to focus on two Agile Development practices which are critical to becoming agile but don’t get very much airtime in the popular write-ups of agile (the ones most likely to be read by people who then decide they must ‘do agile’). One of these is Frequent Customer Feedback and the second is the Definition of Done. Without both of these practices being used properly, I would argue that your agile Initiative is doomed. Both these practices are designed to overcome some of the fundamental problems with more traditional development methods, and I would also argue that in many organisational change management initiatives neither of these is practised and help to explain why change programmes are sometimes less successful than their owners either expected or wanted.<br />
<br />
Over the years, before I became an independent consultant, I’ve been on the receiving end of dozens of change programmes, some of which cost a royal mint and appeared to achieve very little. In one global organisation, a three-year programme of enormous changes was superseded by a second programme with a similar name which appeared to undo everything that the first one did. This may be an extreme example of change mismanagement, but neither Definition of Done nor Frequent Customer Feedback were evident to the majority of people in the organisation. To be honest, I’m not entirely sure that the objectives of the change were publicised other than the launch of the programme by the CEO but that’s a whole different story.<br />
<br />
Internal change programmes are notoriously bad at obeying the project governance that is in place for customer facing projects. Requirements and objectives are often sketchy and based in terms of pre-determined solutions to perceived problems rather than by establishing genuine problems and defining workable solutions using the methods that are mandated for use in customer projects. Most importantly, few quantitative checks are made during the course of the initiative, other than the costs and adherence to a usually arbitrary schedule or set of milestones. And rarely is there a definition of done. Without this DoD, how do we know when the change is complete? Is it when there is no more budget? Or maybe when all the tasks on the project plan have been ticked off? Or maybe it’s just when the initiative gives way to the next one? If we don’t know what the end point of the change is, how can we possibly begin to understand whether it has been successful? How can we start to measure the return on investment and cost benefit or any other benefits?<br />
<br />
In a development environment, it’s relatively easy to create a definition of done. Most good Agile Development teams will have created their own which has been agreed with the product owner. It might include items like:<br />
<br />
- All code in the release has been code reviewed, unit tested, and meets the agreed coding standards<br />
- All code in the release has been through integration and acceptance tests<br />
- All user documentation has been written and peer-reviewed<br />
- All releasable material has been secured into the production environment<br />
- All story criteria have been passed by the product owner<br />
<br />
If the team, including the PO, do not agree that the conditions for Done are met, the code cannot be shipped. This is a commitment that is made up front and cannot be reneged on, and is the primary guarantee that only good quality product is released into the world.<br />
<br />
When you start talking about business change, the DoD is much harder, and if you don't have clear objectives and requirements about what the change is expected to deliver, you haven't got a hope of defining when you’ve achieved it. And yet businesses still seem to think that this is a smart way of working. (Just as an aside, and based on my earlier comments about Agile vs agile, I wonder what organisations use to understand what their goals are for their Agile (agile) Transformations? Let’s not go there now!)<br />
<br />
I’m not going to even attempt to provide you with a list of some potential criteria for helping create the DoD for a change programme. Doing so would be futile because what might work for me won’t work for you, but most importantly your DoD will be completely dependent on the context for your change and your organisational structure and culture.<br />
<br />
Regular customer feedback should really be a complete no-brainer for a change programme. 99% of business leaders acknowledge that successful change programmes are built on engagement and discussion with all the critical stakeholders, especially the people most impacted by the change. But the reality is that a much smaller percentage actually do it, or do it effectively. Telling people that a change is coming and then telling them sometime down the line that the change will be effective from next month does not count as engagement. It barely counts as communication.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiLl9pI7KcvhM0j59jXHKzAIV37_7oSBg9DjwovfO-yKQttJ4w0qWtzYUBVqnmdsWVnSeZ5rIr5ndYqa85rGD_y9VQgiw8AMe4cnI4Sh6I31mVongD87Re3sh59D4T8iOGYspGi4LCZwmas/s1600/adults-brainstorming-desk-1595385.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="1067" data-original-width="1600" height="266" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiLl9pI7KcvhM0j59jXHKzAIV37_7oSBg9DjwovfO-yKQttJ4w0qWtzYUBVqnmdsWVnSeZ5rIr5ndYqa85rGD_y9VQgiw8AMe4cnI4Sh6I31mVongD87Re3sh59D4T8iOGYspGi4LCZwmas/s400/adults-brainstorming-desk-1595385.jpg" width="400" /></a></div>
<br />
There are two clues to solving this regular customer feedback problem in a change programme, and using Agile Development concepts actually makes it a bit easier. The first clue is the use of the word 'regular' which suggests that you may have to perform this activity more than once at the beginning and once at the end. The other clue is the word 'feedback' which suggests that telling people is only part of the story. You need to listen to what they have to say as well, and preferably act on it. Ignoring feedback is bad management, poor leadership and quite honestly simply bad manners, and yet it is still a standard business practice.<br />
<br />
How can Agile Development practices help us better deal with regular customer feedback in our change projects?<br />
<br />
By splitting our activities into time-boxed chunks (you might be more familiar with Sprints but this is a scrum specific term) we actually automatically provide those regular feedback points. Again, to borrow terminology, scrum talks in terms of Retrospectives. But since I want people to stop mixing Agile Development and agile change metaphors, I’d rather not dwell on terminology. Call things what you like, but just make sure that everyone understands what you’re talking about. The point is, at the end of each timebox, you make time with the stakeholders to understand what you have achieved, what has worked, what hasn't worked and what can be done to improve things in the future. You can also get a feel about what new information might be pertinent to the next set of timeboxes and what activities might need reprioritising.<br />
<br />
I'm not suggesting these activities are easy to do in a change management initiative. They are certainly easier in an Agile Development environment, where you have a clearly defined deliverable, namely working software that adds value to the user.<br />
<br />
But no-one ever said Change Management was easy - it's just that there are things you can do to make it less difficult and to minimise the risk of things getting out of control. If you want your organisation to be agile, it's going to require some serious thought about how you approach change in the future.<br />
<br />
Yes, folks, it is true; agile is about a changing mindset and changing the way you do work. There are no blueprints you can follow and make it happen overnight. There is no such thing as Agile Change Management!<br />
<br />
<br />
<br />
<br />
<br />Ally Gillhttp://www.blogger.com/profile/08266980121207923495noreply@blogger.com0tag:blogger.com,1999:blog-4514003879443285921.post-11006952707684567552019-02-13T16:32:00.000+00:002019-02-22T13:13:58.496+00:00Using Agile Development Concepts to Help Manage Organisational ChangeIf you got a chance to read my last post, “<a href="http://allygillcouk.blogspot.com/2019/02/is-agile-change-management-real-thing.html" target="_blank">Is There Such A Thing As Agile Change Management</a>”, you may have thought I was a bit harsh on the New Wave ‘agilisters’ (a collective noun for people obsessed with sticking the word ‘agile’ in front of a business practice and thinking it’ll make a difference). I actually think that most people agreed with me, but I wanted to write this follow-up because there are some positives that come from the Agile obsession and it’s really important to recognise these and not to dismiss something because a whole bunch of people are misrepresenting it.<br />
<br />
But, let’s not be under any illusion; Agile Change Management is not a real thing. Even more importantly trying to shoehorn Change Management and Agile Development into the same pigeonhole is never going to be useful to anyone.<br />
<br />
Change Management is about how we facilitate change activities within an organisation to ensure that we are trying to do the right things, for the right reasons, and with the best interests of the right people as the paramount consideration in our change initiative.<br />
<br />
Agile Development, on the other hand, is a mechanism for building software in such a way that it provides a continuous value stream to the people who need to use the software (as well as making life better for the people who develop that software).<br />
<br />
With that important distinction in place, we’re now in a better place to understand how we can use concepts from one discipline to get better outcomes somewhere else. So, what can we learn from Agile Development that we can use when we are looking at Organisational Change? Can we cross-pollinate ideas from one discipline of building software to another of managing change?<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhgNqX9kfIxQiN1nnnDkQTwlMcI2fldxLMe4zjgq3KiMmLO2P3A7GzP-sXemLiKHmhasdyo4Izs3JkCBqflsAkYRN2nR9T-WOZR36QQ8eGYzh5EcIjmsaGZcpRDjYiBhFU6pJFPFwUj1in_/s1600/bee-bloom-blossom-47039.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="1106" data-original-width="1600" height="276" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhgNqX9kfIxQiN1nnnDkQTwlMcI2fldxLMe4zjgq3KiMmLO2P3A7GzP-sXemLiKHmhasdyo4Izs3JkCBqflsAkYRN2nR9T-WOZR36QQ8eGYzh5EcIjmsaGZcpRDjYiBhFU6pJFPFwUj1in_/s400/bee-bloom-blossom-47039.jpg" width="400" /></a></div>
<br />
<br />
Since there are so many people who think that ‘agile’ is all about whiteboards and stand-up meetings, let’s start with them and get them out of the way. To be honest, I’d suggest these are no-brainers. Much of our work in Change Management is about communication and these two tools are all about improving communication within an agile team. A simple whiteboard is a great way to visualise what’s going on in a change initiative and helps us to understand flow through the system. A whiteboard is great for the change team or even the leadership team to see at a glance what’s going on and a useful driver for those sometimes difficult conversations. It beats a project schedule hands down and can be understood by most people without a detailed explanation.<br />
<br />
In the same vein, the daily (stand-up) meeting is a useful addition to the communication tools at the change team’s disposal, and again could be extended to the leadership team, depending on your organisational context. There’s nothing magical about a daily (stand-up) meeting. It’s what all meetings should be; focused, short, inclusive, and action/outcome oriented. (Daily meetings don’t have to be stand-ups, but to keep them short and dynamic it helps.)<br />
<br />
In my previous post, I hinted that only three elements of the Agile Manifesto were appropriate to Change Management. These were:<br />
<br />
<ul>
<li>Simplicity</li>
<li>Support, trust and motivate people involved</li>
<li>Regular reflections on how to become more effective</li>
</ul>
<br />
The daily meetings and the whiteboards are great examples of some ways to realise these requirements. Regular retrospectives (post milestone reviews) are an additional tool that can be used to further support the third of these. But clearly, there’s a lot more to agile. When we go back to the Agile Manifesto, there are (arguably) three principles which underpin the whole ethos behind Agile Development.<br />
<br />
<ul>
<li>Customer Satisfaction through early and continuous software delivery</li>
<li>Accommodate changing requirements throughout the development process</li>
<li>Frequent delivery of working software</li>
</ul>
<br />
There is a really good reason why these are so important in Agile Development. Often, when we create a product which is highly reliant on software, we have very little idea of what the end product should look like. Even if we do, we often don’t know whether it is possible to achieve. When we first started building large software applications we attempted to get around this problem by analysing and defining everything up front, writing huge specification documents, followed by myriads of design documents and finally cutting the code to bring it all together. The problem with this approach is that when you get to the point that you’re writing the code and the customer (or product owner) wants something changing, it becomes very difficult and very expensive to build that change into the system.<br />
<br />
Agile Development attempts to circumvent the problem by having a vision of the end product, but only developing small chunks of it at a time. Chunks that can actually be of use and valuable to the end user without having to wait for the complete product. This reduces the risk of having to rebuild vast amounts of the system when requirements change, or when implementation problems arise, and hence reduces the cost of the final product. At the same time, it gets over the inherently human problem of not knowing what we don’t know because it enables us to learn more about what we are building as we build it.<br />
<br />
This is where things get tricky when we try and adapt these principles into organisational change (unless of course, our organisational change is all about a large software implementation like an ERP - Enterprise Resource Planning -system). It becomes clear why when we paraphrase the principles in terms of change<br />
<br />
<ul>
<li>Customer Satisfaction through early and continuous change</li>
<li>Accommodate changing requirements throughout the change</li>
<li>Frequent delivery of change</li>
</ul>
<br />
Often, organisational change is not something we can easily do in chunks. Rolling out a new organisational structure a bit at a time over several months brings about chaos - I’ve seen it happen on more than one occasion. The endpoint of an organisational change is usually very well understood, and indeed, changing the requirements of a change initiative during the initiative will invariably cause many problems, and may lead to many more issues in the future when trust is lost in the ability of the leadership to deliver change. Finally, when an organisation become a conveyor belt of change with no respite, organisation change fatigue sets in; the people within the business cannot take on more change and uncertainty and they have no more appetite for it. When this happens, their only option is to push back against the next set of changes, regardless of how important they are.<br />
<br />
While some changes do require a big-bang approach, it is still possible to structure a strategic change programme into a number of tactical initiatives using this agile approach. And instead of defining a huge change programme upfront, designing all the different pieces before finally implementing them, we can use the agile approach to deliver vital pieces of the overall puzzle and constantly adjusting what gets done next by regularly revisiting the requirements and the urgency of their implementation. It’s also possible to build in slack into the frequency of change experienced by different groups in the organisation by changing the target groups on a regular basis. And of course, it is critical to constantly monitor feedback and engage with the affected stakeholders throughout the programme. And when you take an approach like this, it’s even more important to keep your communications flowing, being prepared to explain why you’re taking the decisions to prioritise certain tactical changes over others, and above all, keep things transparent.<br />
<br />
But you know what…Let’s not get ahead of ourselves and start calling this “Agile Change Management”. It isn’t. Because ‘Agile Change Management’ still isn’t a thing!<br />
<br />
<br />
<br />
<br />
<br />
<br />Ally Gillhttp://www.blogger.com/profile/08266980121207923495noreply@blogger.com1tag:blogger.com,1999:blog-4514003879443285921.post-28670273620016554472019-02-01T17:47:00.000+00:002019-06-06T09:37:32.569+01:00Is Agile Change Management A Real Thing?A topic that keeps cropping up in some of the change management forums of which I’m a member is ‘Agile Change Management’ and while I’m happily contributing to the discussions it does seem to me that there is a lot of confusion and speaking potentially at cross-purposes. So I decided to write this piece to help me consolidate my thoughts and hopefully bring some clarity about my own position about Agile Change Management.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEifUH8dhqr6lgkh6JE3Zn1eLDibA_u1PRQv_-iNUkaB5EGPEaEo8G1L5_bHJ3zxTBuxT08-Gg1uIsWEEiRZ_yWiJ_skkLlhRQYOXeMol201D1BYNCh74dX_o31E4Pfv34Nrl8UDup8RzjS4/s1600/action-adult-agile-316769.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="1067" data-original-width="1600" height="265" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEifUH8dhqr6lgkh6JE3Zn1eLDibA_u1PRQv_-iNUkaB5EGPEaEo8G1L5_bHJ3zxTBuxT08-Gg1uIsWEEiRZ_yWiJ_skkLlhRQYOXeMol201D1BYNCh74dX_o31E4Pfv34Nrl8UDup8RzjS4/s400/action-adult-agile-316769.jpg" width="400" /></a></div>
<br />
<br />
To put my own position into context we have to step back in time to 1995 or thereabouts. I was working for a financial services company in a departmental development group and we had taken the decision to rearchitect our entire portfolio which was bursting at the seams. At the time, it was the height of the Object Oriented versus Structured design, analysis and programming method wars, and we went OO. Speed was of the essence to get the full portfolio re-engineered, so we also decided to model our development method along the DSDM rapid application design route. It would be another six years before the Agile Manifesto was published (2001) and it would take a few more years more for Agile to became the new management mantra that it is today.<br />
<br />
In adopting DSMS and the nascent ideas that ultimately became Agile Development, we were looking to do many of the very things that the Agile Manifesto highlights. Primarily, we wanted to deliver value to the customer on a regular basis many times a year. We weren’t big on processes so that wasn’t a big deal to us but we were getting hot under the collar about software quality and all our code was well documented within the source and subject to team code reviews. We had a series of product owners for each application within the portfolio and were co-located with the business people. We weren’t big on project management either - we had product roadmaps and timelines but weren’t wrapped up with project schedules. Ultimately, our overarching goal was to support the business by being part of it, not living a parallel existence as an IT organisation selling to the business.<br />
<br />
Looking back to those days we had pretty much got it right. And we kept it simple. The team collectively made the decisions about how we wanted to operate and management let us get on with it. We worked with the product owners and designers, programmers, testers and support staff all sat in on the design meetings so everyone understood what was going on and had buy-in. No-one had any surprises further down the line, and products were shaped collectively rather than passed from analysts to designers to coders and then thrown to the testing teams. It’s a far cry from the Agile Development Industry of today which has become so complex and convoluted that some of the original signatories of the Agile Manifesto and the very early adopters are trying to distance themselves from the agile movement.<br />
<br />
If the Agile Development world has gone a little bit crazy and spawned its own supporting and lucrative (if somewhat nebulous and smelling of snake-oil) industry, it’s hardly surprising that other people are jumping on the bandwagon and selling agile as a cure-all. So we find Agile Project Management (surely the antithesis of the original intent of the Agile Manifesto!), Agile Management (the ultimate oxymoron?), Agile Testing (we test small parts of the software regularly?) and of course Agile Change Management.<br />
<br />
Let’s step back again for a moment. The dictionary definition of the adjective ‘agile’ is:<br />
<br />
<blockquote class="tr_bq">
having quickness of motion, nimble, active (of body or mind)”</blockquote>
<br />
and for those interested in etymology it hastens back to the 1580s, from Middle French agile (14c.) and directly from Latin agilis "nimble, quick," from agere "to set in motion, keep in movement"<br />
<br />
All of these attributes are highly relevant to modern business and yet modern businesses are set up to be anything but agile. They are juggernauts whereby the time an order is received and acted on at the far reaches of the empire, it has already been rescinded at head office to make way for the next directive. Modern businesses are siloed complexes where internal departments compete with each other for finite amounts of money and people and bicker amongst themselves rather than doing what is right for the customer. Entire departments are set up to manage cross-charges (funny money?) rather than focus on external customer satisfaction. And modern businesses now want to be Agile by doing agile things that were designed for a very specific group of people with a very specific set of needs and desires. So they have stand-up meetings and whiteboards full of stickers instead of departmental sit downs and project schedules (actually they often do both!) so they look agile.<br />
<br />
The point is that they haven’t thought about what agility means. They do Agile, without being agile because they can’t really see that being agile means changing almost all the current ways we do business and the way we do work. And some people will never be able to make that change, because they have too much to lose - because ultimately being agile means giving up the reigns of centralised power, and most senior and middle managers will never be able to do that.<br />
<br />
Which brings me back to the title of the piece. Is there such a thing as Agile Change Management? If we go back to the Agile Manifesto and try to apply it to Organisational Change Management, we can ignore the four values underpinning the manifesto, and we can ignore over half of the principles. I would argue that the only relevant pieces of the Agile Manifesto with respect to OCM are:<br />
<br />
<ul>
<li>Simplicity</li>
<li>Support, trust and motivate people involved</li>
<li>Regular reflections on how to become more effective</li>
</ul>
<br />
and all three of these should already underpin any change management activity within the organisation.<br />
<br />
As for the ceremonies like daily stand-ups, Kanban boards, these are noise. They are tools that you can use but they don’t make change any more agile, they just make it more visible and more transparent (if used correctly). My argument against Agile Change Management is that if you can't do Change Management given what you already know, you're not going to get better using something you know even less about. I don't really subscribe to the idea that Change Management fails. Organisations fail to do Change Management.<br />
<br />
For many of us with a history and good understanding of true Agile Development, the most important aspect of agility is the continuous delivery of value to the customer. And in Organisational Change Management we already have that ability.<br />
<br />
It’s known as Continuous Improvement.<br />
<br />
<br />
<br />Ally Gillhttp://www.blogger.com/profile/08266980121207923495noreply@blogger.com0tag:blogger.com,1999:blog-4514003879443285921.post-91821629718005731912018-12-10T17:26:00.001+00:002018-12-10T17:26:22.380+00:00A Double Standard Is No Standard At All!If there's one thing guaranteed to make me mad in the workplace it's the failure of people to follow internal standards or guidelines for internal projects. In the IT world, this appears to be the normal state of affairs. I've lost count of the number of internal initiatives that I've been involved with which have no requirements (documented or not), no clear objectives, no stated business benefit, no plan, and no effective management per se.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgPxwd60sLzaH3_pvJVJqnrvZJQ7bKnRQxkQXybk0bBC6KZ7X4JOs5U3Wcwr9GMKfca1GMHOugOBt8euZcLpWX0cETwLTvcmbAo-ytW3Fbg2fu4WoLOtCVNfzNjfToRljhUNc966dgkXqib/s1600/DBL+STD.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="1236" data-original-width="1600" height="247" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgPxwd60sLzaH3_pvJVJqnrvZJQ7bKnRQxkQXybk0bBC6KZ7X4JOs5U3Wcwr9GMKfca1GMHOugOBt8euZcLpWX0cETwLTvcmbAo-ytW3Fbg2fu4WoLOtCVNfzNjfToRljhUNc966dgkXqib/s320/DBL+STD.jpg" width="320" /></a></div>
<div class="separator" style="clear: both; text-align: center;">
<br /></div>
These companies often have highly developed processes and procedures covering just about every aspect of their business, and yet internal projects (and programmes) are kicked off on a regular basis without even so much as the back of a fag packet plan.<br />
<br />
How many times have you been tasked with creating a tool to monitor some aspect of your organisation without any of the prerequisites demanded by management for a customer-facing tool? You must have had the conversation that goes...<br />
<br />
<span style="color: purple;">Manager: "Knock me up a spreadsheet to track our widget usage across the organisation. Nothing fancy, but I'll need it for the leadership team meeting first thing in the morning".</span><br />
<br />
<div style="text-align: right;">
<span style="color: blue;">You: "You can use the corporate widget monitoring tool for that"</span></div>
<br />
<span style="color: purple;">Manager: "I don't need the full monty, just a snapshot - it'll only take you a few minutes. You can do it during your lunch break"</span><br />
<br />
<div style="text-align: right;">
<span style="color: blue;">You: "OK, then. I'll have it ready for you early by 14:00" </span></div>
<br />
Back at your desk, you start banging your head against the wood because you know what's going to happen next. The quick and dirty spreadsheet 'project' is soon going to morph into something monstrous and you'll never get an opportunity to eat lunch again. Soon, everyone will be wanting additional features, customisations and modifications (not one of which will be written down).<br />
<br />
I've written and spoken about the dangers of the end-user cottage industry of dashboards in the past but the truth is that major corporations run vast tracts of their business affairs using unregulated and un-auditable spreadsheets. Far more complex initiatives are undertaken in exactly the same way and the outcomes are always the same. And they are not good...for anyone!<br />
<br />
Organisational change is still one of the most difficult undertakings for a business, and yet many of them still believe they can perform it without any understanding, planning or proper management. The metaphor of building the aeroplane while it is in-flight is entirely appropriate. You’ll be familiar with the executive who is parachuted into your department and immediately starts to take control by issuing edicts about how things need to be done, despite having no previous experience in anything to do with what your department does.<br />
<br />
You might think you’ve got lucky when the exec announces he is setting up an internal working party. And then you find that the working party includes all his management cronies and a token member of your department - the one person in the team who is guaranteed to not rock the boat. A few days later you get the memo about the changes and after shaking your head in disbelief you start plotting with the other reliable members of your team as to how to block the change and undermine the new manager. And businesses wonder why change fails.<br />
<br />
Maverick workers may be a pain in the backside, but they often operate for the good of their colleagues. Maverick managers, on the other hand, are often only in it to further their own careers. These kind of parachute appointments are very often temporary, and any damage that is done can often be put right before too long, once the exec has been assigned to another department!<br />
<br />
But if organisations really want their employees to react positively to change, senior executives must keep an eye out for double standards, where managers expect others to behave a certain way, but fail to do so themselves. If managers can’t follow internal processes then their leaders should be asking why not. If the processes are wrong, then fix them. If managers won’t follow internal processes, then either re-educate them or get rid of them.<br />
<br />
A double standard is no standard at all.<br />
<br />
<br />
<br />
<br />Ally Gillhttp://www.blogger.com/profile/08266980121207923495noreply@blogger.com0tag:blogger.com,1999:blog-4514003879443285921.post-45282415129557482752018-11-30T18:28:00.001+00:002018-11-30T20:44:39.715+00:00Collaboration and Innovation: “What we’ve got here is failure to communicate” *<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEibEtusIkNYD9l-19BtvGsbsyNUQHHJ4T3PXd_e1P5fapmD5dShaMURhqSdSx1Vp5jVYp2KT9AiBIVDOazMKFTGTs11sqnY1UMCHgOxN3qOgOu6doJRlpw4Q5g20gjxQAPt2qiZT4mXeilv/s1600/Failure+To+Communicate.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="1067" data-original-width="1600" height="266" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEibEtusIkNYD9l-19BtvGsbsyNUQHHJ4T3PXd_e1P5fapmD5dShaMURhqSdSx1Vp5jVYp2KT9AiBIVDOazMKFTGTs11sqnY1UMCHgOxN3qOgOu6doJRlpw4Q5g20gjxQAPt2qiZT4mXeilv/s400/Failure+To+Communicate.jpg" width="400" /></a></div>
<br />
Show me a recent company mission statement or a set of corporate values and I'm willing to bet that it'll contain the words collaboration and innovation. It'll probably also contain the word agile and maybe lean as well but let's not get sidetracked in the first paragraph.<br />
<br />
Whilst I don’t dispute that innovation and collaboration are ‘good things’, when they appear in high-level mission statements and value propositions, they are usually little more than words plucked off a jargon bingo sheet, fairly meaningless and probably not understood by the people who wrote them any more than the executives and managers tasked to make them happen.<br />
<br />
The biggest misplaced assumption about innovation and collaboration is that these things can be made to happen on demand. Secondly, there is the rather suspect assumption that for businesses to succeed everybody in the organisation must be an innovator and a collaborator. Thirdly and finally I take issue with the assumptions that innovation needs to be centralised and that collaboration and teamwork are synonymous.<br />
<br />
My main issue with these assumptions is that both collaboration and innovation are organic. They cannot be turned on and off like a tap and management cannot force people to do either (at least not successfully).<br />
<br />
I’ve spent quite large portions of my working life as a remote worker so I’ve always been interested in the way ‘home-based working’ falls in and out of management favour. As a remote worker, generally you become a natural collaborator, otherwise, you tend to go slightly deranged. You also become something of an innovator, because there are times when you are the only person who can come up with a solution to a problem you face. Yahoo, IBM and HPE all made headline news when they announced an end to home working because they needed everyone in the office to ensure maximum collaboration. As if being in an office in San Francisco is going to make you any better at collaborating with your colleagues in Bangalore than if you were at home (actually it’s more likely to be the reverse, but let’s not go there).<br />
<br />
I recently came across a question asking how to enhance Global Collaboration in an organisation. The question pertained specifically to a situation where the business comprised a significant itinerant workforce. But regardless of the specifics, I was intrigued by what was meant by “Global Collaboration”. Was there an expectation that management could force people across the world to collaborate, regardless of their role, department, or whatever other artificial organisational constructs you’d care to add? Even if that were the case, why on earth would you want it? It sounds like a recipe for disaster in terms of organisational productivity. You could spend all day in meetings collaborating with people you’d never heard of before about subjects you know nothing about!<br />
<br />
Collaboration needs a driver and a context. Groups of people need to collaborate from time to time - some more than others. And a failure to collaborate is exactly what causes organisational meltdowns on occasion. Organisational failure often occurs at the interfaces within those artificial organisational constructs I mentioned earlier, and more often than not is brought about by the very creation of those constructs such as setting conflicting objectives for sales and marketing teams and engineering teams. Or trying to create an agile organisation one project at a time. When individuals or groups of people understand that they have mutual goals like deliver a product to the customer in the fastest time, it’s amazing how quickly they learn to collaborate.<br />
<br />
In the same way, it’s amazing how people will collaborate in order to innovate a solution to solve a problem. But management doesn’t generally see this as good enough because they are constantly being told (by people who don’t have a clue what they are talking about) that they need to innovate faster to stay ahead. So soft drinks manufacturers, for example, constantly come up with improvements to their age-old, much-loved recipes that no-one likes and no-one buys. They’ve innovated their way out millions of dollars of marketing, R&D and customer loyalty. Of course, they could have gone to their frontline workforce and asked them if they could come up with better solutions to create their existing products (yup - that’s also innovation!), but that’s not enough to satisfy greedy investors and analysts.<br />
<br />
The relatively new fad of creating Centres of Innovation, where good ideas go through various filters before they get approved or rejected and then end up in the hands of people who implement something completely unrecognisable from the initial proposal, sends out an extraordinary message to employees. It says - we don’t trust you to be able to take an idea from nothing to implementation; we need someone better qualified to do that. And in so doing it stifles innovation from the very people who know best what needs to be done.<br />
<br />
If you take a dozen people and put them on a desert island with no interaction with the outside world, they’ll innovate a way to kill each other, after the strongest have collaborated together to find out which of the others to kill first.<br />
<br />
* Quote from the 1967 film, Cool Hand Luke by The Captain (played by Strother Martin)<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />Ally Gillhttp://www.blogger.com/profile/08266980121207923495noreply@blogger.com0tag:blogger.com,1999:blog-4514003879443285921.post-71108032605733659422016-05-10T14:15:00.001+01:002016-05-10T14:28:45.555+01:00Guest Blogger Melina Leary : How to stop your inbox stopping you<i><span style="font-family: inherit;">This is the first ever guest post to appear on my blog. It was written by Melina Leary, my long suffering partner, about the blight that affects so many of us, so much of the time. Enjoy!</span></i><br />
<h4>
<span style="font-family: inherit;">Introduction</span></h4>
<span style="font-family: inherit;">Although the ability to send messages between computers has been possible from the early 1970s, when I started office work in 1987 it was not widely used as a mechanism for communication. Things were so much simpler in the “good ole days” though. I generally worked within co-located teams with our customer not far away. If I needed to consult with anybody, I only needed to glance across the desk or room to see if they were available.</span><br />
<h4>
<span style="font-family: inherit;">Email as a blessing</span></h4>
<span style="font-family: inherit;">Fast forward 30 years with advent of the internet and a major shift in the way we work, team members may now be scattered across a variety of locations around the world. No more glancing across the desk to check out a colleague’s availability to discuss a matter, they are somewhere else and may not even be awake. The email, along with instant messaging, are perfect tools for asking questions or obtaining feedback from someone who cannot be seen or who has such a strong regional accent is difficult to understand on the ‘phone anyway. Email is also perfect tools for introverts, it is so easy to hide behind a computer and fire off an electronic message and avoid a face to face confrontation.</span><br />
<h4>
<span style="font-family: inherit;">Email as a curse</span></h4>
<span style="font-family: inherit;">The problem now is that email is being used too much. I regularly hear colleagues complaining of email overload, especially after taking a few days off. Some are even proud of the amount they get as if it is a sign of their importance. However, heavily loaded inboxes become unmanageable and sap productivity. </span><br />
<span style="font-family: inherit;"><br /></span>
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgcq14ekDwAgk3dR9zqJecuFJ7DCdXBxOPfFnkO-xHLNbfeGnPBjsP7SZ0B9VT-kizZesU8O9AVzDrhYdzwQ0sIP5wxmGXeiONz3DZBQvUpAKYHwxjeLD5VxI8LC0Ya8vHGjM_47hdbcJdH/s1600/IMG_1281.JPG" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" height="400" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgcq14ekDwAgk3dR9zqJecuFJ7DCdXBxOPfFnkO-xHLNbfeGnPBjsP7SZ0B9VT-kizZesU8O9AVzDrhYdzwQ0sIP5wxmGXeiONz3DZBQvUpAKYHwxjeLD5VxI8LC0Ya8vHGjM_47hdbcJdH/s400/IMG_1281.JPG" width="300" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Shouldn't take long to go through 4,294,967,295 messages!</td></tr>
</tbody></table>
<span style="font-family: inherit;">A quick search on Google can bring up a number of ways of managing unruly inboxes, from only checking emails at certain times of day and using the 2-minute rule to respond, to flagging important ones and setting rules for auto filing. However, these are all reactive strategies. I firmly believe that if emails are coming in so fast that you can never get around to addressing them all in a timely manner, then it is time to sit back and plan a solution to the problem.</span><br />
<h4>
<span style="font-family: inherit;">Stop the curse! </span></h4>
<span style="font-family: inherit;">One of the biggest issues I have seen recently is the habit of people to manage entire projects or functions using email as the communication mechanism. There are many other ways of collaborating and sharing information, and the key to doing it effectively for any endeavour is to Plan.</span><br />
<span style="font-family: inherit;"><br /></span>
<span style="font-family: inherit;">Planning means, identifying and understanding your stakeholders; working out who you need to deal with, why, and how they prefer to be engaged or informed. For example, there is no point in sending emails to people who are rarely online.</span><br />
<span style="font-family: inherit;"><br /></span>
<span style="font-family: inherit;">Planning how to engage with your team, managers and customers will help ensure communications are managed. Understand what is needed to be shared by who, when, how often, in what format and how shared, for example:</span><br />
<br />
<ul>
<li><span style="font-family: inherit;">if possible, use collaborative tools and documentation repositories to prevent items from being emailed around. Make sure everyone is aware of the filing mechanism and uses the tool</span></li>
<li><span style="font-family: inherit;">use action logs for unscheduled activities to track who is doing what, and meet to progress actions rather than chase via email. If an email is to be sent out for action, put this clearly in the subject heading "For Action: <subject heading="">" and only include people in the To: field who actually have to perform the action</subject></span></li>
<li><span style="font-family: inherit;">don’t forget the good old fashioned mechanism of talking. If working in a virtual environment, ping the person first via Instant Messaging to check they are available. Talking to someone about a problem takes much less time than crafting a suitably worded email</span></li>
<li><span style="font-family: inherit;">avoid asking for consensus or opinion from more than one person by email. By doing that you open up a communication channels that may not involve you at all and lead to confusion. It is better to get everyone together in a room, on a call or, if email must be used, obtaining responses via a voting mechanism</span></li>
<li><span style="font-family: inherit;">if you are managing a team, impress upon team members that they do not need to copy you in on everything they are doing. Some do this to prove they are doing their job. It is not necessary; progressing can be done via 1-2-1s or team meetings </span></li>
<li><span style="font-family: inherit;">notifications can be sent out via business social networking tools such as Yammer</span></li>
</ul>
<span style="font-family: inherit;">It may not be possible to do any of the above under all circumstances, but using these techniques some of the time will prevent your inbox getting clogged up and missing anything really important.</span><br />
<h4>
<span style="font-family: inherit;">Conclusion</span></h4>
<span style="font-family: inherit;">Email is an essential tool in the workplace for passing on messages and collaborating with others, but, if your inbox is out of control you need to sit back and plan a better way of dealing with your collaborators. Understanding your stakeholder requirements and planning communications will help keep your emails at acceptable levels and as a result, will increase productivity. </span><br />
<span style="font-family: inherit;"><br /></span>
<span style="font-family: inherit;"><br /></span>
<span style="font-family: inherit;"><br /></span>
<br />
<div>
<br /></div>
Ally Gillhttp://www.blogger.com/profile/08266980121207923495noreply@blogger.com0tag:blogger.com,1999:blog-4514003879443285921.post-68702765172133402532016-03-15T14:39:00.000+00:002016-03-15T14:39:09.746+00:00What Exactly Are Change Agents and Change Management?I've spent a large proportion of the last thirty years involved in or running organisational, business and software process improvement initiatives. It was probably two or three years before I realised that I was actually managing change. Back in the late 1980's, business change was far from the talking point it is these days - at least not in my circles (and most definitely not in my manager's circles). When the penny dropped, my professional life changed completely.<br />
<br />
One of the catalysts for me was a book called "<a href="http://www.amazon.co.uk/Agents-Change-Managers-Planning-Projects/dp/1860760902/ref=sr_1_58?s=books&ie=UTF8&qid=1457384073&sr=1-58&keywords=change+agents" target="_blank">Agents of Change</a>: The Manager's Guide to Planning and Leading Change" by Hilary Maher and Pauline Hall. Although it's a long while since I last looked through it, a casual glance at it's condition shows how much use it received in the past.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEizmDMF97V6-jmx8PPC682PCx8OI5iLePL2UuWkH7pe0TcYvbtBlEtAMv2xyyThopLi9iB137Jy7777wF1zzlniQYzZXzWEUv__Mgc5WAgQeqN694fOiVfqeNYSpWl6JzlESuN5JcMODxdj/s1600/change_management.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="226" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEizmDMF97V6-jmx8PPC682PCx8OI5iLePL2UuWkH7pe0TcYvbtBlEtAMv2xyyThopLi9iB137Jy7777wF1zzlniQYzZXzWEUv__Mgc5WAgQeqN694fOiVfqeNYSpWl6JzlESuN5JcMODxdj/s400/change_management.jpg" width="400" /></a></div>
<br />
<br />
Recently I've read a number of articles about "Change Agents" but none of them seem to resonate with my own perception of what a Change Agent is. And yesterday I read an article that even had me questioning what exactly Change Management is. Once again I find myself being frustrated by our use of terminology and how relatively common business terms are perceived so differently by so many people - and that perhaps our adoption of certain terminology actually feeds some of the problems that some of us are trying so hard to eliminate.<br />
<h4>
Change Management</h4>
As I inferred in my opening paragraph, Change Management (or Management of Change) is relatively new in the business world. I doubt that there is anyone who has ever worked someone else who has not been subjected to changes in their working environment without any input to or control over the change. Top down edicts from all levels of management have traditionally been the norm as the command and control culture has predominated across the world of work (and increasingly in government also - but that's a different story).<br />
<br />
Because of that command and control system, managers felt it unnecessary to involve staff in the mechanism of change, which was largely achieved through sticks and occasional carrots. Staff reactions to change were considered irrelevant; The prevailing sentiments were "if they don't like it they can leave", or "we know what's best for the company (or shareholders)", and Fear Uncertainly and Doubt were often the chosen tools for affecting change.<br />
<br />
As people started pushing back and resisting the big brother approach to change, a few enlightened people began to look at the psychology of change and the effects it was having on staff, especially in terms of productivity and staff retention. People began to understand that a chaotic, dictatorial approach to change was not the best way to implement change, and Change Management became one of the key buzzwords of the late 20th and early 21st centuries.<br />
<br />
In my view Change Management involves taking a holistic view to making sustainable change in a organisation, and looking at the change from a people perspective (whilst still understanding the technical and business requirements of the change) rather than simply as a push process whereby complying with the corporate diktat is the only criteria for success.<br />
<br />
Many companies have proprietary 'methods' in place to help manage change - and they usually involve elements such as leadership, communication, collaboration, planning, monitoring and education. My own <a href="http://allygillcouk.blogspot.com/2015/04/5-facets-of-change-revisited.html" target="_blank">5 Facets of Change</a> is a work in progress.<br />
<br />
Even with the concept of Change Management firmly established in the business world, there are still a large number of managers and businesses that force change through the organisation by paying lip service to genuine change management - plans are written, teams established and change agents appointed to carry out the will of management and disregard the will of the people.<br />
<br />
So why am I now coming to the conclusion that the term Change Management is not only wrong but may be harmful? It's down to that word 'management', which still has the connotation of someone managing someone else and an overarching implication that leaders define the change and the staff change.<br />
<br />
What we're really talking about is the Facilitation or Realisation of Change - helping people at all levels of the organisation to shape change, buy in to change, and work collaboratively across the business to make change successful and sustainable. That last word is key - even force feeding change into the organisation can succeed to a certain extent, but it won't take long before people revert back to the previous status quo.<br />
<h4>
The Change Agent</h4>
I have written about change agents before in this blog (posts about <a href="http://allygillcouk.blogspot.com/search/label/Change%20Agents" target="_blank">Change Agents</a>). But once again, the use of the phrase causes consternation from some readers. The implication is that as 'agents' they are management spies or puppets, only there to execute the will of the diktat. I recently used the word 'champions' in the context of change and was firmly rebuked by one reader, suggesting that if we needed people to champion change then"good luck with getting it to stick in the long term".<br />
<br />
I think of the change agent as a layer of protection from misguided management and wayward change initiatives which are not undertaken without due diligence and planning - those ad hoc changes which do far more harm than good. I see these people as "champions" of doing change appropriately, and making sure that staff get to share their issues, ideas and solutions and get heard!<br />
<br />
I see change agents operating at all levels of the organisation, and not all performing the same role. Some will be change process experts, others will be great at building relationships with stakeholders, others acting as devil's advocates, and still others acting as management foils, but collectively they have a single collective goal of making a change work and making the change sustainable.<br />
<br />
<br />
<br />
The problem with terminology is that it doesn't take long for it to become adopted universally and popularised, by which time it's usually too late to realise that we words don't really reflect what we originally intended. What were perfectly good words at the time, become vilified - not because they are bad words, but because people have misunderstood what concepts were being represented and have manipulated things to serve their own purposes. You only have to think about how the term 'agile' has been misused, misinterpreted and misunderstood to appreciate how quickly we make a mockery of ideas that were full of good intentions but get hijacked to serve completely different agendas.<br />
<br />
So Change Management and Change Agents have become enshrined into our vox populi. If I try and come up with alternatives it will only serve to further confuse and obfuscate the original intentions - so I'll keep away from talking about Change Stewards and Steering Change, and some of the other phrases that came to mind while I was writing this. Instead I'll focus on trying to make sure that we have a common and shared understanding about the terms we already have in place!<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />Ally Gillhttp://www.blogger.com/profile/08266980121207923495noreply@blogger.com0tag:blogger.com,1999:blog-4514003879443285921.post-32020132831364136322016-02-21T12:31:00.000+00:002016-02-21T12:31:17.931+00:00You Get By With A Little Help From Your FriendsThere's no shortage of internet articles and books about toxic workplaces, toxic co-workers and how to avid them. But I rarely see articles about the best people to work with, so I've put together my own set of stereotypes of the best sorts of people to have around you in the office. If you can't choose your work colleagues, and you know the types of people to avoid, this guide will help you gravitate towards the folk who might make your working day that little bit more bearable.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj6z9F7qlzom3A1e0-8vgbOp6b9CPCqTZs3gj-I3tQnWDiEDOCpRrvSAkxESwSf65FjSCZI_-bhitu7KegapHg-k0yWj9L-Nqzx_tepoQ8PvngwfaYXXOIkG9VJ87x42aN3725W9YUvKMzI/s1600/Gotoguy.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj6z9F7qlzom3A1e0-8vgbOp6b9CPCqTZs3gj-I3tQnWDiEDOCpRrvSAkxESwSf65FjSCZI_-bhitu7KegapHg-k0yWj9L-Nqzx_tepoQ8PvngwfaYXXOIkG9VJ87x42aN3725W9YUvKMzI/s1600/Gotoguy.jpg" /></a></div>
<br />
<h4>
The Realistic Optimist</h4>
The Realistic Optimist is an ideal change agent. Unlike the perpetual pessimist who argues against change and only sees the negatives (usually before even knowing what is changing), the Realistic Optimist understands the arguments from both sides, and generally accepts that things are going to change regardless, so the best thing to do is make the most of the opportunity. At the same time, the Realistic Optimist is quite happy to argue their corner with management - they aren't going to roll over backwards and let management walk over them. The grass most certainly isn't always greener in their eyes, but it is still green and grass and not a car park.<br />
<br />
You need to look after the Realistic Optimist. It's hard work trying to see the best in everything, and when they fail they will come back down to earth with an almighty bump.<br />
<h4>
The Go-To-Guy </h4>
There are always some people who seem to know everything (whilst actually knowing very little that is correct and even less that adds value). To counter these toxic individuals who just like the sound of their own voice, seek out the Go-To-Guy. The Go-To-Guy is the person who just knows stuff without making a big deal out of it. They've probably been around for a while and have been in a number of different roles - maybe some very senior roles - and have large networks and understand how things get done.<br />
<br />
The Go-To-Guy might not have all the answers, but knows the right person to talk to. The are typically affable, entertaining and self-effacing people who genuinely like to help, and see others thrive in the workplace. They don't need bragging rights and they left their egos behind them a long time ago.<br />
<br />
On the downside, the Go-To-Guy may be a little bit of a 'company guy', and may be just a little hung up over compliance for the sake of it, or even just a little too attached to the status quo. Which after all is what he knows best!<br />
<h4>
The Beamer</h4>
The Beamer is just that person who is always smiling. The person who laughs at all the right jokes (at the right time and in the right places). They are probably quite quiet, diligent and just get on with their work, but their bonhomie is infectious with being tiring. Every office or team needs a beamer!<br />
<h4>
The Influential Unleader</h4>
<div>
The Influential Unleader is the person who always steps up when needed. Voids are usually uncomfortable, and the Influential Unleader sees to it that voids get filled. When management asks for a volunteer it's the Influential Unleader who takes the job on, or is volunteered by their colleagues. They don't need to prove themselves - they've already earned the respect of their peers. They take things on from a sense of duty, and probably to stop an alternative solution being thrust on them and their colleagues.</div>
<div>
<br /></div>
<div>
They are unleaders because they don't have formal leadership roles, and they don't act as despots or dictators in their leadership style. People look up to them, and know that they are in good hands.</div>
<div>
<br /></div>
<div>
Influential Unleaders will never make it to the top levels of the organisation, and even though this is often through choice, they will eventually become disillusioned and move on as they see under-performers and less able people take over the key positions.</div>
<h4>
The Spokesperson</h4>
The Spokesperson is similar to the Influential Unleader (they may be the same person in a small group). They will fill a void of silence, but probably don't have the confidence to take the next step and actually perform the leadership role. But they are incredibly articulate, passionate and have the best interests of the team at heart.<br />
<br />
When the Spokesperson starts a challenge with "I think I speak for the rest of the team when I say...", they usually do. They will be acutely aware of how the members of the team feel, and will not be scared of taking the flack for saying it out loud. But beware of the False Spokesperson who is only speaking for themselves, but hiding behind the team.<br />
<h4>
The Man For All Seasons</h4>
Clearly not an exclusively male role, but a Person For All Seasons or even (Wo)Man For All Seasons doesn't really work. The Man For All Seasons exhibits all the above traits. If you have one of these in your team it should let you off the hook as there will always be someone in your team that has your back.<br />
<br />
But you still need to build your personal skills and aspire to become the Man of All Seasons yourself. When you find yourself in a new team without one, who are you going to call?<br />
<br />
<br />
<br />Ally Gillhttp://www.blogger.com/profile/08266980121207923495noreply@blogger.com0tag:blogger.com,1999:blog-4514003879443285921.post-6069901454890318632016-01-15T09:38:00.001+00:002016-01-15T09:38:12.182+00:00Key Attributes of an Effective ProcessWhen I used to cut code for a living there were a number of attributes we used to look for in a 'good' program (application!). Maintainability, Efficiency, Readability, Flexibility, Reliability, Reusability, Portability and Testability are some of these non-functional or quality requirements that spring to mind. A programmer today may have a slightly different list as development environments have changed and technology has advanced. Security probably trumps portability for example.<br />
<div>
<br /></div>
<div>
A couple of days ago I started writing a post whinging about processes that, at least from a user's perspective, appear to be constantly changing. These are often pretty, bureaucratic changes but are exceedingly frustrating for those on the receiving end of the changes.At the same time I was documenting an existing process as part of the day job, and I started thinking about the quality attributes for a process. What makes an effective process?<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgH66RmPjnXv5KGyqO7oO-oLY-1gVYAhYtqEURgYVbPEdIgNU7hTm7PUQ9BYZ3kXx8K8wa_4c4bQWD6RsBEmRayoyCnpzbUZwEEG4lnTP0oM-bPc0bh7GBR2wJ_qtGbHySk2i3TdxjaLhmE/s1600/spa1.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="214" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgH66RmPjnXv5KGyqO7oO-oLY-1gVYAhYtqEURgYVbPEdIgNU7hTm7PUQ9BYZ3kXx8K8wa_4c4bQWD6RsBEmRayoyCnpzbUZwEEG4lnTP0oM-bPc0bh7GBR2wJ_qtGbHySk2i3TdxjaLhmE/s320/spa1.jpg" width="320" /></a></div>
<br /></div>
<div>
<br /></div>
<div>
I know that many folk would argue that there is no such thing as a good process. but for the rest of us here's my list - written from the perspective of a process user (not purely as a process author)...</div>
<div>
<ul>
<li>Stable - whilst the whole point of continuous improvement is to ensure that processes are kept up to date, there must be a period of bedding down a process before you start changing it. Constantly fiddling with a process, even in the minutiae, irritates and confuses users, and will inevitably lead to some kind of failure before too long as people simply don't know what's right and wrong anymore. Unless a process is shown to be fundamentally wrong (in which case it there should be big questions about how or why it was published in the first place), let a reasonable amount of time pass before updating it. And where processes are cyclical, e.g. monthly, don't make changes every month, especially at the point of execution!</li>
<li>Complete - there are plenty of great examples of how to document a process, but all too often these are ignored, and valuable or even critical information is missing from the process definition. For example, entry and exit criteria are often missed out, sometimes inputs and outputs are only partially listed. Attention to details gives users confidence in the process</li>
<li>Understandable - if you document all your processes as essays, don't be surprised if people struggle to follow them. It's also important to get the level of detail right - don't mix up process definitions with work instructions. Few users actually need to read a process end to end if they are already familiar with it. They are more likely to want to find elements within the process like process inputs or specific roles and responsibilities. If using web based descriptions, draw on good user interface guidelines to hide or show levels of information that people can focus on. If your using more traditional document based descriptions, a tabular approach is often a good way to present information.</li>
<li>Current - people expect to be able to access processes that are up date and relevant for the work they are currently doing. Old, irrelevant processes should be withdrawn and archived if necessary. And publishing process changes is simply not enough - there needs to be communication that processes have changed, and how they have changed</li>
<li>Usable - in the age of corporate intranets, wikis and even SharePoint, there is no excuse in not making processes easy to find, navigate and access. Libraries of documents are no longer relevant nor desirable as vehicles for users to access information. The best process libraries are those that users can interact with, even to the extent of having processes describes from different user perspectives according to their role or function. More importantly, thing about how the process flows from a user's perspective - something obvious to an author may not be so obvious to a user, especially in the heat of the moment when they are battling against a deadline</li>
<li>Simple - many working environments are already unnecessarily complex so your processes need to be documented to help remove the complexity as much as possible, They need to be clear and precise, and focused on the people who do the work - they should not attempt to showcase the author's writing talents!</li>
</ul>
<div>
I'm sure there are other attributes that you may want to add to my list - drop me a <a href="mailto:ally@allygill.co.uk" target="_blank">note </a>or leave a comment and I'll include them in a future post</div>
</div>
<div>
<br /></div>
<div>
<br /></div>
<div>
<div>
<br /></div>
<div>
<br />
<div>
<br /></div>
<div>
<br /></div>
</div>
</div>
Ally Gillhttp://www.blogger.com/profile/08266980121207923495noreply@blogger.com0tag:blogger.com,1999:blog-4514003879443285921.post-89632182288696858192016-01-08T10:47:00.000+00:002016-01-08T10:47:11.469+00:00Why The Shareholder Should Not Be At The Top of the Food ChainEarlier this week I read yet another article about the imminent demise of Yahoo's leadership team due to a letter from an activist shareholder group - who in this case owns less than 1% of Yahoo. OK, 1% of a multi billion dollar company may well be more than I'll ever earn in several lifetimes, but it's still a very small stake-holding compared to all the other investors.<br />
<br />
What struck me was how such a tiny stakeholder thought it had the right to make such demands on a business and why, if it was so unhappy with the business why it simply didn't divest itself of its stake?<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhT1S5F1G7b6cT8URCbVyeA-i91pok5HXLU0bsm8cBFSLhiiJ_WZZ5wD1Puufnsto26fKAJemlnOiinBGVaXCUC9LLLe7AVbAOGgLezCIqXRqsuk0QJJWKCkTd3E0mV0ixJry6-oIjjB-4Z/s1600/activist-shareholder-thumbnail-8bit.png" imageanchor="1"><img border="0" height="225" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhT1S5F1G7b6cT8URCbVyeA-i91pok5HXLU0bsm8cBFSLhiiJ_WZZ5wD1Puufnsto26fKAJemlnOiinBGVaXCUC9LLLe7AVbAOGgLezCIqXRqsuk0QJJWKCkTd3E0mV0ixJry6-oIjjB-4Z/s400/activist-shareholder-thumbnail-8bit.png" width="400" /></a></div>
<div style="text-align: center;">
<span style="font-size: x-small;">(Picture borrowed from Kristen Maxwell </span><a href="http://www.texasenterprise.utexas.edu/2013/03/01/finance/lingo-activist-shareholder" target="_blank"><span style="font-size: xx-small;">Texas Enterprise</span></a><span style="font-size: x-small;">)</span></div>
<br />
When I first started working, there was a very clear mantra that was drummed into my head with remorseless frequency. The shareholder is the king of the jungle - the only reason you are in business is to make money and return the investments of the shareholders. Nothing else matters - not even the customer, and especially not the employees.<br />
<br />
That always seemed to me to be a bit of a perverse way of looking at the world, but everybody was saying the same thing, so it had to be right - and I was a newbie and at the very bottom of the food chain, so what did I know? But the concept has nagged at me right through my working life like a dull tooth ache that won't quite go away completely, and occasionally rears up and hurts like heck.<br />
<br />
In my world I always had the naive perspective that if you treated your staff with dignity and respect they would work their socks off to please the customer (and their managers). The customers would increase their support for the company with increased spending and referrals, and the benefits would be realised by the executives, and ultimately the shareholders. A positive reinforcement loop if every I saw one!<br />
<br />
Finally, it appears that I'm not alone in that ridiculous notion. A reasonably successful businessman called Richard Branson talked about the concept in a recent <a href="http://www.inc.com/eric-schurenberg/sir-richard-branson-put-your-staff-first-customers-second-and-shareholders-third.html" target="_blank">interview</a>. Peter Leeson speaks from the same perspective in his book <a href="http://www.amazon.co.uk/gp/product/1326241443?keywords=orchestrated%20knowledge&qid=1452245722&ref_=sr_1_1&sr=8-1" target="_blank">Orchestrated Knowledge </a><br />
<br />
<blockquote class="tr_bq">
"Unfortunately, in recent years, many management teams have started believing that they work for the shareholders rather than the clients"</blockquote>
<br />
and then suggests that shareholders are often only ever interested in short term speculation (usually with each other) and rarely bring any real value to the company.<br />
<br />
The downside of raising the importance of the shareholder above everyone else is that, ultimately, people start equating the value of stock with the quality and viability of the business (look no further than Apple and the performance of its stock which is completely divorced from the profitability of the business and totally at the mercy of Wall Street analysts who live in a completely alternative reality distortion field). Once you start people thinking there are potential risks to the future of the business, you set a negative feedback loop in progress and the vicious downward spiral begins.<br />
<br />
Meanwhile, global IT giants like HPE and IBM continue to treat their people like mediaeval serfs, constantly under threat of redundancy, and being squeezed of every ounce of loyalty left in them by one-dimensional strategies which are focused purely on cutting costs, rather than improving the business (and their customer service).<br />
<br />
The relentless march towards corporate capitalism will be our downfall and the balance needs to be redressed towards putting real people first, namely employees and customers. After all, what's the point of empowering people by creating agile environments and then making them redundant simply to generate more money for people who can't actually do anything to make the business better?!<br />
<br />
<br />
<br />
<br />
<br />Ally Gillhttp://www.blogger.com/profile/08266980121207923495noreply@blogger.com0tag:blogger.com,1999:blog-4514003879443285921.post-21327934910002882832015-11-23T18:02:00.001+00:002015-11-23T18:02:45.292+00:00Think Global, Act Local - How To Sub-optimise Your Global OperationI think it was sometime in the early 2000s when I first came across the expression "Think Global, Act Local". The phrase has been attributed to Patrick Geddes, a Scottish town planner and social activist, and originated way back in 1915. These days it is a rallying cry for global corporations, and it has appeared in nearly every leadership presentation I have seen over the last 10 years.<br />
<br />
At the time, I was working for a major IT outsourcing company, whose business was truly global, and where corporate shared services were already being farmed out to 'low cost centres' across the world. In Applications Development and Maintenance, we were also beginning to talk about 'follow the sun' development, whereby developers would work in relay teams around the world to build software systems 24x7 in a factory model - but that's another story for another day.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh7gfvTQOC5gu3vRrjUjYdSB-DLDwacPClHIYIBkIKzzBS8HfASoXiXz3gPEmmOWuSnEOIYJA0lXu6BoivssnNnAAN02GOAa16cPA_XILc2V-8BUVJSnsqDqYYW3FgCkUSryjcp42VVU497/s1600/Think+Global+Act+Local+-+Leadership.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="261" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh7gfvTQOC5gu3vRrjUjYdSB-DLDwacPClHIYIBkIKzzBS8HfASoXiXz3gPEmmOWuSnEOIYJA0lXu6BoivssnNnAAN02GOAa16cPA_XILc2V-8BUVJSnsqDqYYW3FgCkUSryjcp42VVU497/s320/Think+Global+Act+Local+-+Leadership.jpg" width="320" /></a></div>
<br />
I remember being quite excited about the 'Think Global, Act Local' paradigm, mainly because I had my fingers in many pies. I was a member of a number of global task forces looking at various elements of our software development activities, whilst being responsible for all business improvement activities across Europe, and also looking after a team of UK based process improvement experts. And for a while things were hunky dory...we achieved an enormous amount, it was fantastic collaborating with people from all over the world and we actually worked in an environment where people understood how the paradigm should work but more importantly what the limitations were.<br />
<br />
When I came across the phrase more recently, I started thinking about how jaded it now seemed, and more importantly how it has been so poorly interpreted by so many management teams that it has probably caused more harm than good. On top of that I realise how naive I was to be taken in by some of these slogans, although I'm pleased that I now finally see them for what they are and that I'm able to think around the consequences of these and other management hypes, although that is largely the result of seeing how things have evolved in the real world, and the problems that have ensued.<br />
<br />
I have two main examples of where the paradigm breaks down. Both involve the transfer of work to places with relatively lower cost bases, which is possibly a very desirable thing to do if you are an accountant, but less desirable when seen from other perspectives.<br />
<br />
In the first example, let's consider the situation where highly skilled knowledge workers form an operational hub in a low cost region. Depending on the location, it is possible to hire very skilled people (often contractors) at slightly lower rates than they might expect from their home base, but who benefit from the reduced costs of living abroad. The company benefits from lower wages bills and generally lower operating costs by setting up such hubs. A win-win situation it would appear.<br />
<br />
It's only when you start working that the problems become evident. And in my experience the single biggest issue is that all collaboration and communication is done electronically. You rarely, if ever, meet the people you support, and your lives are spent working in sound bytes of information, struggling to catch people for a few moments of their time.<br />
<br />
In other words, support staff can only provide a sub-optimal service to their front line colleagues. No matter how hard we try, we are limited by the problems inherent using in electronic communication alone - technical issues, misinterpretation of messages, misunderstandings, language issues - all of which are potential issues when working face to face, but compounded horrendously when our only interface to our colleagues is through a computer.<br />
<br />
[The irony of this situation is that often the work could easily be done by contractors tele-commuting thereby dispensing with the need for office space and the associated costs of doing business. Personally, I would be perfectly comfortable working from my own home, on a lower day rate, than having to relocate to an office on the continent, incurring the costs of renting an apartment, paying management companies to represent me and still not having face to face collaboration with the people I support]<br />
<br />
In the second example, whole functions are relocated to a low cost centre. These are often administrative functions, such as invoicing, procurement or payroll. It may seem quite obvious that these ‘self-contained’ functions can work remotely, servicing requests from across the globe. However, this assumption fails to take into account the biggest single weakness that is inherent across all organisations, regardless of size, longevity and maturity. Most organisational dysfunction occurs at departmental interfaces.<br />
<br />
Some organisations have taken this relocation of function to an extreme. Payroll is located in country 'x', procurement is located in country 'y' and invoicing is located in country 'z'. And of course, all the transactions originate locally and then start their long and intricate itinerary across the world. Even some seemingly trivial activities that used to be performed locally in a matter of seconds now take a week or more to fulfil, assuming there are no issues with the original request. If an issue does arise the error has to be backtracked through it's travels and then start all over again.<br />
<br />
Many of the organisations who have divested their back office activities across the four corners of the world are simultaneously embarking on 'Lean' and 'Agile' initiatives. Because they have no real understanding of what 'Lean' or 'Agile' really mean, they fail to see the irony of their actions.<br />
<br />
Think Global, Act Local, in many respects, is the antithesis of Lean and Agile. Saving money by relocating certain functions at the expense of operational efficiency and effectiveness is almost certainly not going to lead to a net gain against the bottom line. People in higher cost centres are being hindered by the delays in transactions preventing them from realising their own operational effectiveness. Time is spent chasing up requests, often being passed from function to function, as there is no longer any clear overall ownership of the process. In fact, the whole thing smacks of an exercise in job creation, whilst at the same time, hundreds of skilled people with unique domain, customer and product knowledge are being made redundant (before being re-employed as much higher cost contractors).<br />
<br />
If businesses took a moment to map out their end to end processes, looking at such things as value chains and process topography and topology, before they shipped out their support functions, they may realise the potential folly of their actions.<br />
<br />
As usual, there are more dimensions to executing business processes than that of cost alone! And any Lean expert, worth their salt, will understand that optimising all your sub-functions in isolation, out of context, and without a holistic overview, will lead to the overall process being completely sub-optimised...and probably completely dysfunctional...especially to the people who depend on it!<br />
<br />
<br />Ally Gillhttp://www.blogger.com/profile/08266980121207923495noreply@blogger.com0tag:blogger.com,1999:blog-4514003879443285921.post-75321531070993686892015-09-23T16:07:00.000+01:002015-09-24T11:05:49.306+01:00The Change CentreI read an article a couple of days ago called <a href="http://www.forbes.com/sites/jurgenappelo/2015/09/22/the-change-habitat/" target="_blank">The Change Habitat: Why 70% of Change Managers Are Wrong</a> by Jurgen Appelo. I’d need a lot of convincing before accepting much that was written in the article, but it got me thinking about a problem I’ve seen in many organisations struggling to succeed with their change initiatives. <br />
<br />
A common denominator in many organisations where there is a history of problematic change is a lack of a change management competence. By that I mean that there are :<br />
<ul>
<li>no corporate change method or common approach to change </li>
<li>no recognised subject matter experts who can assist in change initiatives</li>
<li>no change management tools or assets to help change leaders and teams</li>
<li>no lessons learned data to help future change programmes</li>
</ul>
In other words, change is usually performed in an chaotic way and is dependent on the skills and ability of the individuals leading any specific change project.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhZ7i6aTkVt5Z_hWDmJX3qCl9Ka3UwkBy3AWXLdmRCoEHiiRSgeOeOrsVpd-4fBL-VEhvN_IVSZn9r5QLxNA77tZCOwLY4mDJPzMBTaePBLZUsR6G_NCf29c6x13T4y9hrksfL5g5t2Pxv6/s1600/Change-Mgmt175030664.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="213" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhZ7i6aTkVt5Z_hWDmJX3qCl9Ka3UwkBy3AWXLdmRCoEHiiRSgeOeOrsVpd-4fBL-VEhvN_IVSZn9r5QLxNA77tZCOwLY4mDJPzMBTaePBLZUsR6G_NCf29c6x13T4y9hrksfL5g5t2Pxv6/s320/Change-Mgmt175030664.jpg" width="320" /></a></div>
<br />
<br />
Most IT organisations involved in project work have a set of project management standards and some form of development/support lifecycle in place, along with supporting governance processes. They usually have a set of standard templates for key deliverables - a project plan (not just a schedule), status reports, budgets and outlooks, and requirements and specification documents. They have mechanisms for raising change requests and recording defects and issues. New projects and new members of staff use the materials already available rather than having to reinvent them every time.<br />
<br />
Very few organisations I’ve worked in have a similar set of assets available for managing change initiatives. People who are asked to manage change initiatives either have to try and make do with the existing project management templates or need to build their own. The problem with using standard project management assets is that they are rarely adequate for projects other than technical ones. And as I suggested in my post from August 2014 (<a href="http://allygillcouk.blogspot.co.uk/search/label/Project%20Management" target="_blank">Unifying Technical Project Management with Management of Change</a>) there are significant differences between the two types of project, and there are additional things that need to be considered for change projects.<br />
<br />
By establishing a Centre of Competance (CoC) for organisational change, with a defined lifecycle, toolkit and group of dedicated change management professionals a company can begin to establish a consistent approach to running change programmes, large or small, thus greatly increasing the potential success of any individual initiative.<br />
<br />
There are some caveats with such an approach. Exactly how you set up your CoC will depend on your organisational culture, history of change, and operational structure, but here are some ideas.<br />
<br />
The lead of any such group should be a recognised expert in organisational change management, with a reporting line to a C-Level executive. It should be understood that the team as a whole acts in a support capacity, like internal consultants. Individual change initiatives are owned by their executive sponsor who is responsible and accountable. Members of the team may act as change managers for specific initiatives and in that capacity become responsible and accountable to the executive sponsor for that change. <br />
<br />
The centre of compentance maintains records of lessons learned and continuously improves its change management assets over time. It is subject to the same quality controls as other parts of the business, including business/quality assurance, internal audit and organisational governance. The group is centrally funded as a shared service across the business as part of the 'change the business’ budget.<br />
<br />
There should be a consistent core of team members and other members of staff may be co-opted into the team on specific initiatves to increase the knowledge, understanding and awareness of change management through the wider organisation.<br />
<br />
An additional responsibilty for the Centre of Competance is to co-ordinate all change within the organisation. This enables the CoC to manage the big picture of change within the business. The CoC performs basic impact analysis and due diligence against all potential changes before they launch. This is critical to understand where effort is being potentially duplicated (or worse!) and to establish where there may be synergies between apparently independent initiatives. It helps the business establish priorities and most importantly makes sure that the change is adequately thought through before being launched. Recommendations are fed back the steering board who make the final decisions on which initiatives should proceed, be put on hold or cancelled.<br />
<br />
The role of the CoC should be communicated to all staff - and they should be encouraged to interact with it. Having an open and transparent change organisation is key to getting people on board. If the CoC is kept behind closed doors its very purpose will be undermined.<br />
<br />
Building a Change Centre will take some time and success certainly won't happen overnight. There may still be issues regarding change projects, but fixing these issues should become easier and your change initiatives should become less painful. More importantly you are setting a foundation for sustainable change in the future - and you can be sure there will be plenty more change to come.<br />
<br />
<br />
<br />
<br />
<br />
<br />Ally Gillhttp://www.blogger.com/profile/08266980121207923495noreply@blogger.comtag:blogger.com,1999:blog-4514003879443285921.post-20984474158743036092015-09-13T11:57:00.000+01:002015-09-13T20:19:03.485+01:00Teamwork - Eight Characteristics to Describe a Great TeamBack in March this year I wrote a post about <a href="http://allygillcouk.blogspot.co.uk/2015/03/teams-in-workplace-flogging-dead.html" target="_blank">Teams</a> where I suggested that the managerial obsession with team building is sometimes not only inappropriate but actually has a negative effect on the individuals being shoe-horned into an artifical construct.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgKJ9HJFnC1s_y-nFGKQsiEW67xFOeWBAVqWXSNgk3Mu8q8we2dRDyiTNjkDxyaGgRxxH9KqRIegcnhrohi3Mu33AZSwlDhWnIDq83w0qN-2NIY2u-BKglrN_VGwwByLWmZdMgj4HD_iiYp/s1600/2.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="208" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgKJ9HJFnC1s_y-nFGKQsiEW67xFOeWBAVqWXSNgk3Mu8q8we2dRDyiTNjkDxyaGgRxxH9KqRIegcnhrohi3Mu33AZSwlDhWnIDq83w0qN-2NIY2u-BKglrN_VGwwByLWmZdMgj4HD_iiYp/s320/2.jpg" width="320" /></a></div>
<br />
I’ve continued thinking about teams and teamwork and recently started reading "<a href="http://www.amazon.co.uk/gp/product/1576751554?psc=1&redirect=true&ref_=oh_aui_search_detailpage" target="_blank">Teamwork Is an Individual Skill: Getting Your Work Done When Sharing Responsibility</a>” by Christopher M. Avery. I’m not very far through the book but I’m already beginning to agree with what I’ve read so far. Whilst reading on the train back from London last night a thought struck me about what a team means to me.<br />
<br />
<ul>
<li><strong>T</strong>rust</li>
<li><strong>E</strong>mpathy</li>
<li><strong>A</strong>cknowledgement</li>
<li><strong>M</strong>otivation</li>
</ul>
<br />
What struck me as I wrote this down was that it applied to both a team in the ’traditional' sense of the word - namely a group of individuals collaborating closely to achieve a shared end result - as well as a bunch of people pigeon-holed together for organisational convenience.<br />
<br />
I don’t believe there’s any need to look at the words individually. They are common enough and dictionary definitions should suffice. But when you take the words collectively it doesn’t take long to notice that they are the words we implicity think about when we think of friendship and social interaction. In other words, the people we like to choose to hang out with in a non-work environment are the people: <br />
<ul>
<li>who we trust and who trust us</li>
<li>who we have some empathy with and who can empathise with us</li>
<li>who acknowledge us for who we are </li>
<li>and who motivate us in our daily lives - who support us when we’re down and urge us on to bigger things</li>
</ul>
I recently spent some time working in Prague with a group of project quality managers from various parts of the world. None of us were acquainted before we started working and each of us was assigned a set of projects to support. We primarily worked as individuals but were classed as a team from an organisational perspective. We started as strangers and when I left at the end of my contract we had become good friends. We had also become a ‘team' because each us were exhibiting those characteristics in my list. I don’t believe that it’s a coincidence that some of the best sporting teams and business teams are largley made up of people who have close social ties.<br />
<br />
No matter how much I would like it, the characteristics of a successful social circle are not enough to build a successful operational unit. There are some other characteristics required, the characteristics that determine how successful teams achieve their goals. The whole concept is commonly called teamwork and there are four important characteristics that help teams do great <i><b>work</b></i>.<br />
<br />
<ul>
<li><b>W</b>in-Win</li>
<li><b>O</b>pportunity</li>
<li><b>R</b>esults</li>
<li><b>K</b>nowledge</li>
</ul>
<div>
Successful teams look for Win-Win situations. Compromise on anything less is deemed a failure, so great teams are exceptional optimists who find ways of working where everyone gets something and no-one comes out a loser. Crucially, win-win situations are achieved by honest means, there's no bluffing, everything is open and transparent.</div>
<div>
<br /></div>
<div>
Good teams look for opportunities - how can we do this better? What else do we need to help exceed our customer's expectations?</div>
<div>
<br /></div>
<div>
Great teams are results oriented. They understand implicitly what is required and they use measurement carefully and wisely to ensure that what they deliver is what is wanted and to the expected standards. They don't do stuff that doesn't add value to the end result - sometimes even going below the corporate governance radar to achieve the desired results (without breaking the law!).</div>
<div>
<br /></div>
<div>
Continuous learning is an essential characteristic of any individual who wishes to succeed. In a team or collaborative environment it's all about how the individuals share that knowledge and how they urge each other to look further than their existing boundaries and concepts.</div>
<div>
<br /></div>
<div>
I still believe that much of the material written about high performing teams is garbage, written by people who have never experienced how a high performing team actually operates. I'm lucky enough to have that experience. I'm sure there's much more to be said on the subject, but for now I'm comfortable with my eight characteristics that help describe TEAMWORK.</div>
<div>
<br /></div>
<div>
<br /></div>
<div>
<br /></div>
<div>
<br /></div>
<div>
<br /></div>
<br />Ally Gillhttp://www.blogger.com/profile/08266980121207923495noreply@blogger.comtag:blogger.com,1999:blog-4514003879443285921.post-90402910292801043152015-08-28T10:44:00.000+01:002015-08-28T10:55:02.088+01:00Quality - What's It Really All About?I've spent a lot of time recently (far too much I fear) looking and occasionally participating in some of the LinkedIn Quality Forums. Most of these have been the ISO 9001 type forums rather than domain specific. With ISO 9001 being a generic quality standard, it’s not surprising that the participants in these forums come from all walks of life, from aerospace to telecoms, from supply chain managers to certification body auditors, and from quality directors to quality engineers. Occasionally there are people like myself - who are primarily involved with knowledge workers.<br />
<br />
The biggest take-away I’ve had from these forums is that consensus amongst quality professionals is rare, that tempers seem to flare far more than in other forums I frequent (including some of the ‘agile’ oriented groups) and that you could lock a group of quality folk in a room for a month and they’d still be no closer to defining what quality really is!<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjnt-itrZVkkBCrq7NUyK7giGMv1IkyLqxYtjbLEnYiwHlegT9XmUliTjxqC6T6_-b91CoJiSHiUHNKVoOLPd2GaVkNVp4JmSp45tNLU1ZGP2grpmlYGbpDnBELRXrKXUx7ygEwM59QZ6LE/s1600/quality01.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="187" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjnt-itrZVkkBCrq7NUyK7giGMv1IkyLqxYtjbLEnYiwHlegT9XmUliTjxqC6T6_-b91CoJiSHiUHNKVoOLPd2GaVkNVp4JmSp45tNLU1ZGP2grpmlYGbpDnBELRXrKXUx7ygEwM59QZ6LE/s200/quality01.jpg" width="200" /></a></div>
<br />
<br />
So, if there’s so much discord between people who actually spend their lives and earn their keep from working in quality, what chance do the rest of us have. I include myself as one of the rest of us quite deliberately as these days I think of myself as a business person who happens to have some hands-on understanding of quality matters in some very specific situations - namely the IT industry and more specifically in software development.<br />
<br />
Looking for a standard definition doesn’t really get us very far. I’m not even going to bother with a dictionary definition because it’s so vague but here’s Wikipedia’s entry:<br />
<br />
<blockquote>
Quality in business, engineering and manufacturing has a pragmatic interpretation as the non-inferiority or superiority of something; it is also defined as fitness for purpose. Quality is a perceptual, conditional, and somewhat subjective attribute and may be understood differently by different people. Consumers may focus on the specification quality of a product/service, or how it compares to competitors in the marketplace. Producers might measure the conformance quality, or degree to which the product/service was produced correctly. Support personnel may measure quality in the degree that a product is reliable, maintainable, or sustainable. A quality item (an item that has quality) has the ability to perform satisfactorily in service and is suitable for its intended purpose.</blockquote>
<br />
The clue as to the problem is clearly stated in the second sentence which is so important that I’ll quote it again.<br />
<br />
<blockquote>
Quality is a perceptual, conditional, and somewhat subjective attribute and may be understood differently by different people.</blockquote>
<br />
My experience of quality is mostly internally facing, supporting the group of people who collectively have responsibility for developing the IT product or service, be they managers, developers, testers, analysts or even salespeople, HR, and finance. This is my set of primmary customers, and there is usually some interaction or interface with a client side quality person. The products I have traditionally had responsibilty for are the processes, artifacts, workflows, data and tools that my customers need to be able to produce the best products they can for their customers.<br />
<br />
It’s been evident for many years that trying to apply traditional product and manufacturing quality tools in a knowledge working environment is somewhat futile. Conceptually, there are great ideas that can be applied in both manufacturing and knowledge based industries. A great many quality principles can be applied universally, but principles, ideas and tools need to be aligned closely to the environment they are to be used in. In other words, they are almost always contextual.<br />
<br />
An inspection process (let’s not get involved for now about whether inspection is a good or bad thing) in the software development environment is very different to the inspection process on an automotive production line. Six Sigma out of the box, doesn’t work well in the software development environment - if for no other reason than the original principles were designed to work with highly repetitive automated processes where human interaction is much less than when developing software which is highly dependent on individuals. We have a similar situation where Lean Manufacturing ideas applied to an office environment without some serious tailoring and adaptation leads to the type of nonsense I described in my previous <a href="http://allygillcouk.blogspot.co.uk/2015/07/a-lean-excuse-for-not-thinking.html" target="_blank">post</a> where desks were marked out with the 'optimised' positions for computers, keyboards, mice, telephones, etc. regardless of whether a person was right or left handed.<br />
<br />
Ultimately, it doesn’t matter too much if there isn’t consensus between quality folks coming from different contexts. What’s important is that people in the same organisation have a consistent view of what quality means in their very specific context. I’m not talking about the slogans and banners that seem to adorn so many office corridors and walls, but a real shared understanding of what is expected from your people when it comes to quality in the workplace, and an up front statement of what your people can expect from their quality department. And then we all need to act and behave accordingly.<br />
<br />
If we work on the old adage that "quality is everyone’s responsibility", then this is the very least we can do. <br />
<br />
<br />
<br />Ally Gillhttp://www.blogger.com/profile/08266980121207923495noreply@blogger.com0tag:blogger.com,1999:blog-4514003879443285921.post-49553115006980601742015-07-02T16:26:00.001+01:002015-07-02T16:26:46.840+01:00A Lean Excuse for Not ThinkingRecently a former colleague posted an article on a social media network entitled "<a href="http://www.processexcellencenetwork.com/lean-six-sigma-business-transformation/articles/the-history-and-simplicity-of-lean-process-improve/" target="_blank">The History and Simplicity of Lean Process Improvement</a>". The author, Brian Hunt, suggests that elements of modern 'lean' can be traced back to ancient and mediaeval times. He then goes on to talk about modern Lean implementations and specifically Six Sigma techniques are often shoe-horned into an organisation with little thought for the people who actually do the work. Having had first hand experience of this, where both management and external consultants colluded to create a version of Lean that bore no resemblance of anything remotely approaching process <b style="font-style: italic;">improvement</b> I couldn't help but chuckle at his example of a UK Government implementation of Lean which included marking out the required position of pens, telephones and other desk furniture for optimum productivity.<br />
<br />
But my comment to Bianca, was more along the lines that we've a long established tradition, especially in IT, of jumping on bandwagons like Lean, Agile and a plethora of other 'methods' over the years, whilst at the same time throwing common sense and considered thought into the wayside.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgtSqEnTzeaI4MdLGGlZ_wklF1cb9COa2gMkuHMUjD-2cRprjyzJeWM3qtnLkwq52zxz3pJ7TvSOlFJhlp9YWMsKU9J7UAOV1eQbcMdOO2fUO68oJodGolnwIKD_HuoDLCoTB9rmSc7T29I/s1600/SixSigma_something_new-560x240.gif" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="171" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgtSqEnTzeaI4MdLGGlZ_wklF1cb9COa2gMkuHMUjD-2cRprjyzJeWM3qtnLkwq52zxz3pJ7TvSOlFJhlp9YWMsKU9J7UAOV1eQbcMdOO2fUO68oJodGolnwIKD_HuoDLCoTB9rmSc7T29I/s400/SixSigma_something_new-560x240.gif" width="400" /></a></div>
<br />
<br />
Now I'm all in favour of new ideas, old ideas being regurgitated, or even incongruous ideas being thrown in the mix and muddled together to create something innovative. What I'm not in favour of is the latest fad being seen as a silver bullet to solve every problem regardless of how suitable or unsuitable it may be.<br />
<br />
If you look at the job market for project managers these days very few of the advertised positions do not include Agile in them. For process improvement positions, a black belt in Six Sigma is pretty much a mandatory requirements, although Lean Six Sigma is preferred.<br />
<br />
The reality is that very few organisations operate a truly agile environment (those that have adopted Scrum shouldn't even be advertising for project managers) and in fact some good old fashioned project management and good governance improvements would be a much better way to improve results than blindly deciding that 'we need to be Agile' without genuinely understanding what that means.<br />
<br />
Similarly, organisations with a track record of failed process improvement initiatives would probably be better off looking at their organisational change management processes (or lack of them) than attempting to implement a Lean Six Sigma improvement programme (whatever that is!) and expecting it to succeed in spite of history....select your favourite maxim<br />
<br />
<ul>
<li>those who fail to learn from the lessons of the past are doomed to repeat them</li>
<li>stupidity is the practice of repeatedly doing the same thing in the expectation of getting a different outcome</li>
</ul>
<div>
Unfortunately there are too many managers and leaders out there who behave like the relative who gives you green jumper every birthday because you twenty years ago said you'd like a green jumper. They jump on ideas and inflict them on their people, because they've stopped thinking properly in the internet age. It's easier to find out about a new idea by reading an article on LinkedIn and stamp it across the business without a second thought than it is to actually work out what the problem is and determine the best approach to solve it using the most appropriate tools and techniques before then implementing the change using good change management practice.</div>
<div>
<br /></div>
<div>
I'm still amazed at the number of organisations that launch an improvement programme, or roll-out a new tools without actually doing any analysis of the problem, let alone putting together any requirements. And absolutely not thinking about the consequences of their actions!</div>
<div>
<br /></div>
<div>
The best consultants and practitioners are not the ones who pigeonhole themselves into a trending method or ideology. The most successful people are those who keep an open mind, understand how different concepts, principles, ideas and tools actually work and how to get the best from the synergies between all the ingredients in the melting pot. They won't always succeed overtime, but at least they'll have a better chance than the trend followers and the ones seeking out the next silver bullet.</div>
<div>
<br /></div>
<div>
<br /></div>
<div>
<br /></div>
<div>
<br /></div>
<br />
<br />
<br />Ally Gillhttp://www.blogger.com/profile/08266980121207923495noreply@blogger.com0tag:blogger.com,1999:blog-4514003879443285921.post-51408658107544089052015-06-16T15:23:00.001+01:002015-06-16T15:23:18.401+01:00Blueprints for Success or Recipes for Disaster?I've seen a few articles recently about using 'blueprints' for the successful implementation of organisational change, especially in the IT industry. I rarely read beyond the title because I believe there is a fundamental problem in the concept of using a blueprint for anything other than what the original term designated, namely: <div>
<blockquote class="tr_bq" style="color: #222222; font-family: arial, sans-serif; line-height: 1.24;">
<span class="_Tgc"><span style="font-size: x-small;">A <b>blueprint</b> is a reproduction of a technical drawing, documenting an architecture or an engineering design, using a contact print process on light-sensitive sheets. Introduced in the 19th century, the process allowed rapid and accurate reproduction of documents used in construction and industry.</span></span></blockquote>
<div style="color: #222222; line-height: 1.24;">
<span style="font-family: inherit;"><br /></span></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiQBjygRW_DD2g6xbh6nq5M09t8csKkshPbZM0Fo7OCJrImLTZmOIzcKlieSYVqTeiQUjs3sllE5Fq4uysliVHTOGK1Usx5nJ0xtAwLCd4XJs2_-tKOY6iw0LKO83dds63awXakzZ0h86eH/s1600/Blueprint.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="213" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiQBjygRW_DD2g6xbh6nq5M09t8csKkshPbZM0Fo7OCJrImLTZmOIzcKlieSYVqTeiQUjs3sllE5Fq4uysliVHTOGK1Usx5nJ0xtAwLCd4XJs2_-tKOY6iw0LKO83dds63awXakzZ0h86eH/s320/Blueprint.jpg" width="320" /></a></div>
<div class="separator" style="clear: both; text-align: center;">
<br /></div>
<div style="color: #222222; line-height: 1.24;">
<span style="font-family: inherit;">I know there will be people out there accusing me of being pedantic and that over time the term blueprint has come to mean a template, plan or design that may or may not be reusable. But the fact is that many people will associate the concept of a blueprint as being a very detailed schematic without which certain projects will be doomed to fail. From there you might be then be forgiven in thinking, that if you have a proven blueprint, you are guaranteed success for future undertakings. You probably couldn't be further from the truth.</span></div>
<div style="color: #222222; line-height: 1.24;">
<span style="font-family: inherit;"><br /></span></div>
<span style="color: #222222; font-family: inherit;"><span style="line-height: 1.24;">As a leader, it took me precisely two change </span></span><span style="color: #222222;"><span style="line-height: 19px;">initiatives</span></span><span style="color: #222222; font-family: inherit;"><span style="line-height: 1.24;"> to work out that </span></span><span style="color: #222222;"><span style="line-height: 19px;">blueprints don't work in that context - and in fact very rarely work in IT projects of any description, unless they are relatively simple, repeatable infrastructure projects. As soon as the level of complexity is increased, the blueprint becomes a millstone rather than an aide.</span></span><br />
<span style="color: #222222;"><span style="line-height: 19px;"><br /></span></span>
<span style="color: #222222;"><span style="line-height: 19px;">Having worked within organisational project and process improvement teams for some years, I eventually found myself responsible for setting up and managing a new team from scratch. Having built a very successful group with a global reputation, I was asked to repeat the process with a larger organisation. Over-enthused with my previous success I made the assumption that I could use the 'blueprint' and repeat what I had previously achieved. What I failed to take into account was that even a few hundred miles away, the culture within the same organisation was completely different from where I'd come from. My 'blueprint' failed and so did I. </span></span><br />
<span style="color: #222222;"><span style="line-height: 19px;"><br /></span></span>
<span style="color: #222222;"><span style="line-height: 19px;">Except in very small companies, cultures are often very different across the business - different attitudes and sub-cultures prevail between departments, and even within the same department there may be further sub-cultures between different buildings or even different floors in the same building. When companies go across countries or continents, the differences will magnified enormously and any previously </span></span>successful <span style="color: #222222; line-height: 19px;">blueprints will be mostly worthless.</span><br />
<br />
<span style="color: #222222;"><span style="line-height: 19px;">There are, however, alternatives to blueprints which can help enormously to tilt the scales of change in favour of success. Using a change management framework, either homegrown or from external sources is a necessity not an option (yet many large organisations still fail to understand this and wing it with all their change programmes). Integrating good project management practice into your change process will help enormously. </span></span><br />
<span style="color: #222222;"><span style="line-height: 19px;"><br /></span></span>
<span style="color: #222222;"><span style="line-height: 19px;">The greatest chance of succeeding with change initiatives is to make use of the expertise in your organisation that is hidden in plain sight - the people who do the day to day work, not managers and consultants who have their own agendas. Involving people from the outset will help prevent you from making dumb decisions, from disenfranchising the work force, and for misunderstanding or misinterpreting the organisation's ability and desire to handle specific changes. </span></span><br />
<span style="color: #222222;"><span style="line-height: 19px;"><br /></span></span>
<span style="color: #222222;"><span style="line-height: 19px;">Blueprints are fine if all the materials and conditions and constraints defined within those blueprints are available or can be met as specified. If they aren't, then the blueprint is probably no longer valid and needs to be modified. </span></span><br />
<span style="color: #222222;"><span style="line-height: 19px;"><br /></span></span>
<span style="color: #222222;"><span style="line-height: 19px;">A half decent cook will be able to follow a recipe and adjust things as they go along to allow for deviations in ingredients, number of diners, time available and a myriad of other variables. If you are leading change initiatives you need to follow the same principles. It won't take long to find out that it's the recipes that help you succeed and the blueprints will guarantee your failure!</span></span><br />
<span style="color: #222222;"><span style="line-height: 19px;"><br /></span></span>
<br />
<div style="color: #222222; line-height: 1.24;">
<span style="font-family: inherit;"><br /></span></div>
<div style="color: #222222; line-height: 1.24;">
<span style="font-family: inherit;"><br /></span></div>
<div style="color: #222222; font-family: arial, sans-serif; font-size: 13px; line-height: 1.24;">
<br /></div>
</div>
Ally Gillhttp://www.blogger.com/profile/08266980121207923495noreply@blogger.com0tag:blogger.com,1999:blog-4514003879443285921.post-67197824709484423742015-06-15T14:12:00.000+01:002015-06-15T14:12:44.229+01:00Standard Disillusionment I've been getting increasingly disillusioned with standards and certifications as I've grown more experienced, older and wiser. And it's not always the standards themselves, though increasingly that is also the case. It's the bodies that own and curate the standards, the organisations that administer them and the people who act as judge, jury and executioner for all things related to a standard.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhu_h-EZGf-2Ufk1dW-rqVg9ABKRiQcnsAQ3HGJwoi0yfxxDjuXKpnKLEUjGY5uc98Tx3HaaJT7dAYrkvnE6kvvdUVJB8kdscJ0ygBfV-QEvRV9QdUsBN7tp5upro04rKF3jZx8P93Whtwq/s1600/XKCD+Standards.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="170" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhu_h-EZGf-2Ufk1dW-rqVg9ABKRiQcnsAQ3HGJwoi0yfxxDjuXKpnKLEUjGY5uc98Tx3HaaJT7dAYrkvnE6kvvdUVJB8kdscJ0ygBfV-QEvRV9QdUsBN7tp5upro04rKF3jZx8P93Whtwq/s400/XKCD+Standards.png" width="400" /></a></div>
<br />
<br />
I used to think that standards were useful. There are probably some standards which still are useful. These are the ones regarding industry specific rules and regulations which are designed to benefit people's safety and well-being. But generic quality standards appear to be being continually dumbed to such an extent that they are becoming increasingly meaningless and irrelevant.<br />
<br />
ISO 9001 in particular has had a chequered history. When I first started using it many people were of the opinion that it didn't matter how you interpreted it. As long as you did was you said you were going to do - even if it was plainly wrong - you could gain your ISO 9001 certification and be a 'quality organisation'. The 2000 release did much to regain faith in the standard, but the forthcoming release appears to be propelling it back into the dark ages.<br />
<br />
Much of the current problem with today's 'standards industry' is just that - it has become an industry in its own right and responsible bodies are milking their consumers for every penny they can get. For example it will cost you $79 (about £50) to purchase the 56 page <b><i>draft</i></b> version of ISO9001:2015 which isn't due to be finalised until the end of the year.<br />
<br />
The key word with a generic standard is interpretation. I've suggested on more than one occasion that quality people fall into one of two camps - those who focus on compliance and telling people what to do (not necessarily ever having done it themselves) and those who understand that the world isn't black and white but made up of many shades of grey and a multitude of other colours, tints and hues. These are the people who have actually done the job, look for pragmatism over compliance and add genuine value to the people they support. They have no need to hide behind rigid interpretations of standards because they understand that different situations require different interpretations and approaches. You only have to look at some of the LinkedIn quality forums to see this for yourself!<br />
<br />
When I'm in the role as a quality manager this disillusion with standards can be seen as both a curse and benefit. As a standard becomes more woolly and vacuous it does allow more scope for interpretation which enables me to promote some of my personal business agendas - like reducing organisational tendency to focus on things that really benefit no-one (not even the people pushing them!). At the same time, I have to be careful about voicing my dissatisfaction which could be seized on by the anti-process brigade as an excuse not to adhere to any process - even the good ones.<br />
<br />
I'd like to think that the worm will turn - but I'm not going to hold my breath. We seem to go from one extreme to the other. The draft ISO 9001:2015 standard as stated previously runs to 56 pages and gives little guidance regarding interpretation. The ITIL version 3 framework (we can argue another time over whether this is a genuine standard) now runs to just under 2000 pages and costs over £250 - but is summarised in 300 pages for a tenner (as in the <a href="http://www.amazon.co.uk/ITIL-foundation-handbook-Stationery-Office/dp/0113313497/ref=pd_sim_14_2?ie=UTF8&refRID=0RM7PM7E9882SWXESA72" target="_blank">ITIL Foundation Handbook</a>) and far less in some of the pocket guides. Much of the rest is simply padding. I wonder if the authors thought that they needed to create hundred of pages of documentation simply to justify the cost.<br />
<br />
Standards need to be precise enough to be of value. They need to be affordable enough to find global acceptance, not just in big corporations but in small, one person businesses, and the cost of applying useful and relevant standards needs to be clear and transparent to the business owner.<br />
<br />
I've recently worked in a number of major corporations in financial and pharmaceutical domains where they see no need for ISO 9001 amidst the other regulatory standards they have to adhere to - and it believe this trend will increase unless the people writing, publishing and administering the standards begin to get their acts together and start thinking of their customers and the folk who have to implement standards in their own organisations.<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />Ally Gillhttp://www.blogger.com/profile/08266980121207923495noreply@blogger.com0tag:blogger.com,1999:blog-4514003879443285921.post-76385849687119423452015-06-03T13:38:00.002+01:002015-06-03T13:38:35.804+01:00Meetings - Corporate ProcrastinationHands up if you've been in a useless meeting this week. It's Friday, so I'm guessing most people reading this have probably been in several useless meetings by now. If you're very lucky your useless meetings may have been interspersed with some useful activities some which involve people other than yourself but would you call them meetings?<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi4jbereuZlW3UjPNRPnUs9O4irox3WvXN09jMo7F5BPDfsGpA1LUBDhEgJGPNQLdBMTeM3BDefGhyaqqX8ykc4Idioii2NFOlic9oqXdf4cLF8QR7lorIbPitTr5yLrcttzUEhyphenhyphen7Ixm5wj/s1600/meetings.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="242" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi4jbereuZlW3UjPNRPnUs9O4irox3WvXN09jMo7F5BPDfsGpA1LUBDhEgJGPNQLdBMTeM3BDefGhyaqqX8ykc4Idioii2NFOlic9oqXdf4cLF8QR7lorIbPitTr5yLrcttzUEhyphenhyphen7Ixm5wj/s320/meetings.jpg" width="320" /></a></div>
<br />
<br />
I could write a few paragraphs about how you could make your meetings more effective. They'd include having an agenda, an outcome, the right people invited, and having those people prepared for your meeting. <br />
<br />
I could extend that list of good things to do in advance of your meeting with some advice on how to run your meetings more effectively. They'd include turning up on time, sticking to your agenda and purpose, keeping people focused and included, not having laptops and phones in use, and keeping brief minutes, at the very least recording any actions arising and decisions made.<br />
<br />
But the best solution, is simply to consider the alternatives to having the meeting in the first place.<br />
<br />
Even when scheduled in advance, every meeting you convene is going to cause someone an inconvenience, including yourself sometimes.<br />
<br />
<ul>
<li>Since they accepted the invitation your lead engineer may have suddenly come up with an idea to solve a problem that's been nagging around for a week and now has to break their train of thought to up sticks to attend you useless meeting</li>
<li>Your product manager may have spent most of the day in useless meetings and hasn't had a break or even lunch and is becoming less and less engaged whilst thinking about his evening meal</li>
<li>The marketing manager is on leave so you'll have to update her on the outcome of your meeting as soon as she gets back - so you've already scheduled another meeting for the two of you</li>
</ul>
<div>
There are dozens of valid reasons why people have something better to to than sit around talking about stuff when they could be doing useful stuff. Admittedly, the options almost always involve disturbing someone, but it's almost always better to annoy one person at a time than a whole bunch of people simultaneously. So here are some alternative options:</div>
<div>
<ul>
<li>Put your discussion items in an email and ask the most appropriate people to comment on them within a specified time. This at least allows the individuals to schedule their time to suit them rather than finding a mutual time that is inconvenient for everyone</li>
<li>Go and talk to someone over a coffee (or pick up the phone if you're not co-located) for an informal chat when it is convenient for you both</li>
<li>Save your topic for inclusion in another meeting where a suitable action can be taken on how to proceed - you might not need a full meeting to get a resolution</li>
<li>Allocate a fixed time every week to discuss a bunch of little things that don't each need the disruption of a full blown meeting</li>
<li>Consider whether the subject matter itself actually needs to be discussed in the first place. Half the meetings that take place in the office are about things that are so unimportant that they don't warrant further discussion let alone a whole meeting!</li>
</ul>
</div>
<div>
Meetings are great for making you look busy, and great for giving you something to do when you're bored but there are better solutions to cover both those situations. If you can cut down on the number of useless meetings you set up and have to attend, it might even make the useful meetings work even better!</div>
<div>
<br /></div>
<div>
<br /></div>
<div>
<br /></div>
<div>
<br /></div>
<div>
<br /></div>
Ally Gillhttp://www.blogger.com/profile/08266980121207923495noreply@blogger.com0tag:blogger.com,1999:blog-4514003879443285921.post-44912264644385232182015-05-22T12:01:00.000+01:002015-05-22T12:01:01.163+01:00Orchestrated Knowledge - not really a book review!<ul style="border: 0px; list-style: none; margin: 0px; padding: 0px; vertical-align: baseline;">
<li class="contact-field" id="relationship-email-item-0" style="border: 0px; margin: 0px; padding: 0px; vertical-align: baseline;"><div style="font-style: inherit; font-variant: inherit; line-height: inherit;">
<span style="font-family: inherit;">I'm not big on technical book reviews, not reading them and definitely not writing them. And I'm not really going to start now, because in my opinion, technical books tend to be either useful or not, and my reviews won't add to their usefulness or lack thereof. However, I do feel quite happy recommending books, articles and other useful sources of well thought out argument in pursuance of understanding - 'orchestrated knowledge' if you like.</span></div>
<div style="font-style: inherit; font-variant: inherit; line-height: inherit;">
<span style="font-family: inherit;"><br /></span></div>
<span style="font-family: inherit;"><span style="font-style: inherit; font-variant: inherit; line-height: inherit;">Peter Leeson is a veteran process improvement and change management expert and a very popular speaker on the conference circuit. I've been fortunate enough to hear him speak on several occasions and I invariably come out of his talks wishing I had his ability to get my messages across in plain English, without worrying about political correctness and without mincing words. </span></span><br />
<span style="font-family: inherit;"><span style="font-style: inherit; font-variant: inherit; line-height: inherit;"><br /></span></span>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhxeBMExqrPdXAAqjVn-6cSxujVfDdsxhXc2X8nWK0IVGyOrJj5jSbatpjwV1Lxy7w51_9hVZ6wh7Ify5aq9gmtM1vvQW4pRC9kaC7500MvN1Us5p0vdKWn2nZXhzrrXs-Sxpd1smNCKqHU/s1600/Orchestrated+Knowledge.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="320" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhxeBMExqrPdXAAqjVn-6cSxujVfDdsxhXc2X8nWK0IVGyOrJj5jSbatpjwV1Lxy7w51_9hVZ6wh7Ify5aq9gmtM1vvQW4pRC9kaC7500MvN1Us5p0vdKWn2nZXhzrrXs-Sxpd1smNCKqHU/s320/Orchestrated+Knowledge.jpg" width="225" /></a></div>
<span style="font-family: inherit;"><span style="font-style: inherit; font-variant: inherit; line-height: inherit;"><br /></span></span>
<span style="font-family: inherit;"><span style="font-style: inherit; font-variant: inherit; line-height: inherit;"><br /></span></span>
I've often wondered why Peter has never published a book - his <a href="http://www.qpit.net/" target="_blank">website</a> is filled with papers and presentations which he has been generous enough to share with anyone who cares to seek them out - and he has enough experience to fill several volumes of anecdotes alone.<br />
<br />
At last I can stop wondering as Peter recently published "<a href="http://www.amazon.co.uk/Orchestrated-Knowledge-Peter-Leeson/dp/1326241443/ref=sr_1_fkmr0_1?s=books&ie=UTF8&qid=1432292072&sr=1-1-fkmr0&keywords=orchestrating+knowledge+peter+leeson" target="_blank">Orchestrated Knowledge - Managing the organisation through knowledge</a>". Orchestrated Knowledge isn't a large book at a tad over 130 pages, but it's a big book in terms of practical advice, background information into why things are the way they are, and explanations of theories regarding process and change management. There are plenty of anecdotes as well and the whole package is based on Peter's exposure to many real issues faced by companies trying to improve the way they work.<br />
<br />
If you want to help improve your organisation and you only read one book this year I would suggest you go out and buy a copy. Now. Because the sooner you read it, the sooner you'll be able to put some of Peter's suggestions into practice.<br />
<br />
<br />
<br /></li>
</ul>
Ally Gillhttp://www.blogger.com/profile/08266980121207923495noreply@blogger.com0tag:blogger.com,1999:blog-4514003879443285921.post-23189239300972914782015-04-27T19:10:00.000+01:002015-04-27T19:10:10.808+01:00You Don't Know What You've Got 'Till It's Gone<blockquote class="tr_bq" style="text-align: center;">
"Don't it always seem to go<br />
That you don't know what you've got<br />
Till it's gone " </blockquote>
<div style="text-align: center;">
<br /></div>
are lines from the 1970 Joni Mitchell song "Big Yellow Taxi" which was an early reflection of environmental blots on the landscape.<br />
<br />
Those lines work on so many levels from reminiscing about personal relationships, missed opportunities and regrets about leaving situations or places. But it struck me that they can apply equally well in a business context, particularly during organisational changes.<br />
<br />
I can think of numerous situations where I've felt this way, and where I've thought (futilely) about the reasoning behind the decisions which caused these feelings. The helplessness when groups or teams (or even whole departments) are broken up or disbanded and their members reposted to different parts of the organisation. The despair when talented professionals with unique subject matter expertise are made redundant, whilst drifters and far less talented individuals keep their jobs. And the sadness when great managers and leaders choose to leave because they no longer feel they can live with the direction the business is heading.<br />
<br />
What I find most disheartening is that these events rarely provide any genuine benefit and, at least in my experience, have generally had the opposite effect of what was intended. Why? Because the people responsible for making the decisions didn't think carefully enough about the consequences of their actions, or if they did, they didn't ask the right questions of the right people who could help them see the potential error of their ways.<br />
<br />
One of the problems of organisational reshuffles (which I'd argue are often changes for changes sake) is that incoming managers are often more keen on imposing their vision of how things should be than taking a few weeks or months to understand what they are inheriting. As a result of this zealotry to change (which is often driven by arrogance), the proverbial babies get thrown out with the bathwater.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgRn0kOUB0C-1Hj8SBo8FqFIS4U7dkrtcp2i6EhyxKfJlxtEBlJEftnUb3XqJZ0I8v5sqjtGVjMs_Discw3mvzmHR8VyvItSdWvTlomox6mG1Z8VL5VpJKMSka6eGYdkoF7GWRUTB9P4CD_/s1600/baby.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgRn0kOUB0C-1Hj8SBo8FqFIS4U7dkrtcp2i6EhyxKfJlxtEBlJEftnUb3XqJZ0I8v5sqjtGVjMs_Discw3mvzmHR8VyvItSdWvTlomox6mG1Z8VL5VpJKMSka6eGYdkoF7GWRUTB9P4CD_/s1600/baby.jpg" height="240" width="320" /></a></div>
<br />
<br />
I remember in one organisation where I was contracting, a new manager, with no operational experience in the area he was taking over, explained to his inherited team that he needed an additional manager to run the team because he personally had too many other direct reports - but none of the permanent employees in the team were experienced enough to take on the role - despite each of them having twenty years subject matter expertise and most of them having managed similar teams in other organisations. All but one person either left the company or sought alternative positions. The knowledge base, value of the group (and moral) in that group plummeted over the course of three months.<br />
<br />
In far too many situations the people that make the decisions ultimately end up reversing them and attempt to rebuild the teams or groups they previously broke up (although they might make some name changes to try and save face). The problem is the damage has generally already been done. Once you lose the trust of those key people and the bonds and networks they have built up, nothing you can do will rectify what has taken place. (And rest assured, bringing people back to their old roles as contractors won't help, and will prove just how wrong you were in the first place!)<br />
<br />
When it's gone it's gone, and you can only rue the fact and hopefully learn enough that next time you find yourself in the same situation, you don't make the same mistakes.<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />Ally Gillhttp://www.blogger.com/profile/08266980121207923495noreply@blogger.com0tag:blogger.com,1999:blog-4514003879443285921.post-7622751846512876922015-04-20T11:49:00.000+01:002015-04-20T11:49:01.508+01:00I Am Not A Resource...I Am A PersonThe most frequently repeated quote from the 1960's cult TV series, The Prisoner, is probably "I am not a number, I am a free man". Much has changed since then, and global corporations now rule the world. I'm repeatedly find myself getting drawn in to discussions resonating around a similar theme in this brave new world where managers insist on calling me a resource. I am not a resource, I am a person!<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjtDsL7dbo2i36Zq-QoKceE-e52AurVK9Y8AeI3c9mOX9ppjRR2_oC5iITbNIDllcDFOazwmDr04bpbJzA5h_bQRGY-gJgTgbnpo5vksMyYOrD3Wp9k1Nv88VXOp7pQm3gYXclEi0Z9J_HI/s1600/Not+a+Number.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjtDsL7dbo2i36Zq-QoKceE-e52AurVK9Y8AeI3c9mOX9ppjRR2_oC5iITbNIDllcDFOazwmDr04bpbJzA5h_bQRGY-gJgTgbnpo5vksMyYOrD3Wp9k1Nv88VXOp7pQm3gYXclEi0Z9J_HI/s1600/Not+a+Number.jpg" height="240" width="320" /></a></div>
<br />
<br />
Some folk say I get too worked up about this - they make counter claims that terminology doesn't matter, or that the groups that look after people are Human Resource departments (didn't they used to be Personnel Departments?). But, to me, words are important, and just because some groups have redefined certain words to suit their own agendas doesn't mean that they are right and it certainly doesn't mean that we don't have the right to complain. But let's get back to the point.<br />
<br />
According to Wikipedia, the first use of the term Human Resources, in a modern connotation was in 1958 by E Wright Bakke - an American economist (which I guess says it all!). In my view a resource is passive, an inanimate or insentient object, like a computer, or a milling machine or a desk. It may require due care and attention to keep it functioning effectively, but it doesn't have needs that it can articulate or negotiate. A resource, in this sense of the word, can be moved around, redistributed, taken apart and rebuilt for a different purpose.<br />
<br />
This dispassionate use of the word resource to describe people only continues to fuel the apparently insatiable appetite of institutional shareholders and market/financial analysts to demand head count reductions as their key measure of how to cut operational costs. It's a lot easier to tell the CEO that they need to cut out 1400 resources to improve productivity than it is to sack 1400 people and screw up their lives. Resources feature on balance sheets, people don't. I was recently incensed by an <a href="http://uk.businessinsider.com/morgan-stanley-wants-more-cuts-at-yahoo-2015-4?r=US" target="_blank">article </a>about Yahoo where a Wall St. analyst was demanding that Marissa Meyer needed to fire a further 1400 staff in order to match Facebook's or Google's productivity rates. Because that's the only strategy he could understand. He couldn't appreciate that in a organisation already suffering from morale issues, further job losses would almost certainly lower productivity even further. And he certainly couldn't seem to understand that productivity can be improved by different means, far more effectively and successfully. And in a sustainable way.<br />
<br />
Next time you look in the mirror, will you see a resource staring back at you or will you see a reflection of yourself; a real, flesh and blood person with needs, emotions and feelings?<br />
<br />
<br />
<br />
<br />Ally Gillhttp://www.blogger.com/profile/08266980121207923495noreply@blogger.com0