Monday 1 December 2014

Location, Location, Location...

I first read Peopleware by Tom De Marco and Timothy Lister not long after it was first published in 1987. I was still cutting code for a living, learning my trade (as I hope I continue to do so some 30 years later) and had little enthusiasm for going into management which appeared to do nothing except stifle my creativity.

The whole of the second section of the book is about The Office Environment. It made interesting reading to me when I first read it and it makes even more interesting reading now, largely because, in the twenty seven years since it was originally published, no-one who has anything to do with office or facilities management seems taken the blindest bit of notice of it.



Since reading Peopleware, I have worked in hundreds of offices, all over the world and in many different industries. With one or two exceptions, most office environments I have encountered have exhibit the same characteristics that De Marco and Lister described as being detrimental to productivity, especially amongst knowledge workers.


Whilst some organisations have taken steps to build collaborative workplaces and others have gone down the green and environmentally friendly spaces, many organisations continue to cram their knowledge workers into large open plan offices which are more like chicken batteries than areas to encourage the type of focus and concentration that is conducive to high productivity.


In fact, things have got progressively worse as more and more work is farmed out to low cost centres in other parts of the world and the volume of conference calls increases (in both number and noise level!). One office in London that I worked in (thankfully only once a month) was more like a school refectory than a software development hub. Space was at such a premium that workers were denied even the basic privacy proffered by a cubicle. Some 500 people shared that space, and there were three floors with exactly the same layout.


The whole nature of globalisation brings into question whether large corporations will ever be able to become genuinely lean or agile as close collaboration becomes increasingly difficult. Some of my work increasingly sees me isolated from the people I would normally expect to be closest to. On some contracts I have never met my colleagues face to face, and will probably never do so. As “shared services”, like quality, process management and even project management become outsourced, the nature of the relationships of people within projects become more complicated, less personable and more remote (literally and figuratively), and I struggle to understand how this can benefit anyone except the bean counters. 

As an introvert, who generally dislikes the notion and reality of conducting business over a telephone, I sometimes wonder how much longer I’ll be able to last in this new world, which relies far more on the ability to make yourself heard and understood over the airwaves, than the old social mechanisms of building nurturing relationships with real people, who more often than not have become genuine friends as time goes by.


Homeworking does help relieve some of the inherent problems imposed by noisy, impersonal, factory farm offices. My home environment is considerably quieter, and it’s much easier to link up with colleagues via video, which at least gives a semblance of dealing with other humans, not just disembodied voices. I have the ability to spread out, I don’t need to worry about clean desk policies, I don’t mind having meetings in the middle of the night to be able to connect with colleagues across three continents (well I don’t mind as much, as long as I’m free to organise my days around this).
But ultimately, I have real doubts about the future of businesses that continue to think of their knowledge workers as items in a warehouse, stacked high and precariously and with no real sense of connection to their neighbours.



Farmers have long known that the better they look after their livestock, the better the end product. Those same farmers also understand that although it may cost more to reach the goal, people will always pay for a premium product if they feel that they are getting value for their money. Cutting costs without continuing to provide a healthy environment for workers to thrive in is completely counter-productive, and ultimately these organisations will pay the price for their lack of understanding.  Maybe if all managers, CEOs and CFO read books like Peopleware, they might actually begin to appreciate what a lot of their employees have understood for many years!





Tuesday 25 November 2014

The Illusion of Agile - Are You Truly Agile?

Do you work in a truly agile organisation or is it just your department, or maybe only your immediate project that is displaying agile tendencies? If you answer with either of the latter two options then you are probably nowhere near as agile as you think you are and you are almost certainly nowhere near as agile as you would like to be or have the potential to be.


I first got involved with agile development back in the mid/late 1990s. Those were the days before the Agile Manifesto (2001) and I don’t even remember using the word agile back then (except in a non-IT context).  Back then we called it Rapid Application Development, and my exposure to this type of development was through the Dynamic Systems Development Method (DSDM). But for the purposes of this post I'll use the term agile for convenience.
At that time the organisation I was working for was at something of a crossroads. Our application portfolio for credit management systems had been unassailable in market leadership term in both functionality and quality. But competitors were beginning to snap at our heels, and the user interface was starting to look jaded, and execution performance and speeds were lagging. And even more importantly the overall architecture of the portfolio was creaking so badly that many more changes would be likely to cause fractures and breaks.
Microsoft was in the final throws of releasing the first 64-bit version of Windows and object and component engineering methods had now stabilised to such an extent that they could realistically be used in a commercial environment. After some careful consideration we decided to redesign and rewrite the entire portfolio to align to the 64-bit platform, and take full advantage of OO and CBD techniques. We also made the decision to move to a rapid application development environment.

I had been put on point to define the method and processes for the new development and was then tasked to act as the project manager for an initial pilot. I was helped considerably by an external consultant who was a leading expert in this field and who was working for our tool supplier at the time. We adapted DSDM and integrated the OO and CBD into an overall development framework and took a small group of senior developers with us on the journey. We also made sure that we had the support and backing of our key business managers, and the whole team was trained appropriately according to their roles.

To cut a potentially long story short, we were not Agile. Although we successfully reduced the lead time for our pilot project from several months to three weeks, we then had something of a set-back. I had to take a couple of critical weeks off work after an accident.  During these two weeks, ourinitial timebox, the lead developer moved the goalposts by deciding to trash all the code libraries and components we had purchased and rewrite them in-house from scratch. On my return, the project was in meltdown - not a single line of code had been written to meet the business requirements, and the estimated time to complete the library code was now twice as long as we had scheduled for the entire project. It was immediately clear that I was going to be the fall guy for this cock-up so I fell on my sword and quit before I could be axed (I already felt like I'd been stabbed in the back!).

[As an aside, I put my hand up to being part of the problem as well as part of the solution. This was the first large change project I'd had responsibility for, and I knew little (nothing?) about proper process management or management of change (and nor did any of my managers and leaders!). Clearly not everyone was on board, perhaps the reasons for the change were not suitably articulated or communicated, and perhaps some people felt left out of the process, despite trying to make it as inclusive as possible. I felt abandonned and pretty hard done by at the time - but the lessons I learned were invaluable, and it turned out to be the start of a whole new direction for my career!]

At the start of the last paragraph I stated we were not Agile. We had an illusion of agility. We had an agile method and some agile tools. We most clearly did not have a shared vision of what agile meant to us, and we absolutely did not have a shared agile mindset. In hindsight I am fairly certain that the pilot would have failed even if we'd stuck to the original plan and used the bought in code and components. People had embraced the idea of doing things faster, but they didn't recognise that by doing things faster, certain other behaviours had to be left behind. For developers it was writing home grown code for everything (and being in complete control), for managers it was the comfort of status meetings and status reports and dictating the work to be done(and being in complete control), and for business owners it was the ability to be removed from the day to day development work (and having to take responsibility and accountability for making decisions on the spot).

With the power of hindsight I'm sure that sooner or later the pilot project would have got caught up in corporate bureacracy - like mandatory training, overtime bans, re-organisations, office moves and the like, because it was only a small group of people who were going agile. And there's the rub. No matter how agile you are, or even your team may be - there are likely to be a whole bunch of people who are still caught up in the bad old ways of command and control, and they will almost certainly put a spanner in your agile world. There might even be some people within your team who don't really get it, and you'll have to find ways to deal with them - but that's a matter for another post.

So, next time you ask yourself whether you are truly agile, think very carefully. Agile is different things to different people, but it is not a method or a set of tools or even a group of people who are trained in agile concepts and methods. Agile is about doing things differently, and the only way you can do things differently and succeed is by having everyone on board and on the same page. If there is a single group that impacts on your work who isn't bought into what you are trying to achieve then I don't believe that you can even begin to consider yourself truly agile.



Friday 24 October 2014

Change Debt - No Second Chances

In the past few years ‘Technical debt’ has become a fairly hot topic. Using the description from Wikipedia, ‘Technical debt’ is a metaphor referring to the eventual consequences of poor system design, architecture or development within a codebase. The debt can be thought of as work that needs to be done before a particular job can be considered complete or proper. If the debt is not repaid, it will keep on accumulating interest, making it hard to implement changes later on. Unaddressed technical debt increases software entropy.'

When I was cutting code, way back in the mid 1980’s we had the problem, there just wasn’t really a name for it. And back then, we had a different way of dealing with it. I was writing programme during one of the most volatile periods of platform change – from mainframe to PC, from MS-DOS to Windows, and from stand-alone to client-server architectures. And each time the platform changed, we did a fairly significant amount of re-architecting, re-design, refactoring and rewrites.
The modern day business drivers of time to market and reduced cycle times were less important then, especially in the niche markets that I was working in. Speed of execution, features and reliability were our main drivers. In the last job where I did still write code I was tasked with improving quality and maintainability and our efforts went a  long way to protecting us from technical debt.

I haven’t written commercial code for nearly 20 years now. But having been involved in dozens of organisational change programmes, I believe they share a similar problem to ‘Technical Debt’. For want of a better expression, I’ll refer to it as ‘Change Debt’ – which we can define as the cost of failing to adequately plan a change or making hasty or ill-considered decisions when implementing change within and across an organisation.
The key difference between Technical Debt and Change Debt is that Technical Debt creeps up on you over time and ultimately engulfs you if you do nothing about it, wheras Change Debt is more like owing money to a loan shark and will probably cause you considerable harm almost immediately.
The real problem with Change Debt is that it is often irreversible. Once you've made the critical (bad) decision (or not made it) you are largely stuck with the consequences - and not only for the lifetime of your current initiative, but potentially for future initiatives.
So, when you are planning your next change programme, take a few extra moments to think carefully about what you are doing, what and whom you are going to impact, and consider the consequences of your decisions and actions from different perspectives.
You may not get a second chance!
 
 
 

 

 

 

Tuesday 26 August 2014

Bring Purpose and Value Back to Project Reviews

In the past 30 years I’ve attended hundreds upon hundreds of project status reviews in various capacities - sometimes as the project manager (‘victim’), more often as a general stakeholder (‘muzzled bystander’) and on a few occasions as a review lead (‘master inquisitor’). I can’t honestly remember a single instance where the review has actually proved directly useful to anyone involved. I’d go as far as to suggest that the best project status reviews were the ones that got cancelled, thereby freeing up time to do something useful instead.


But, before going any further, let’s just clarify what I mean by a project status review. I’m talking about the regular management reviews which usually take place at the month end, after the (usually equally useless) project status report has been sent out. These reviews, scheduled months in advance, generally consist of a bunch of managers and stakeholders who ask lightweight questions about the project status. Often these are the same issues that have been addressed in the project status report but which they haven’t got around to reading yet, and usually they are the same questions they asked the previous month. In the worst scenarios, the project manager must endure a series of review boards in which increasingly senior managers ask the same questions expecting some miraculous transformation of project status during the course of the review period. Some hope!

Project managers adopt different strategies to deal with the project status review. Some come armed with spreadsheets and projections and try and bluff their way through with numbers. Others overwhelm the audience by pointing fingers and blaming the suppliers, the customer, the government and anyone else in the hope of shifting attention away from themselves. Yet others simply talk, and talk, and talk in a brazen attempt to use up the allocated review time without actually revealing anything at all.

And generally the members of the review board nod and mutter and occasionally proffer words of encouragement or caution or huff and puff about the situation, but rarely take any action. It’s all part of the game. And it’s all a waste of time and energy.

Don’t think that I’m advocating that all reviews are a waste of time - only the ones that take place because “that’s what managers do”, “that’s what the process dictates”, or for whatever other forgotten or misunderstood reason. If scheduled reviews are the established norm then review leaders and participants should at least be encouraged to ask useful and more demanding questions.

This is especially true with improvement or change programmes where project costs and schedules may appear to be on-target in terms of creating deliverables, but the real hard work - actually embedding the change and winning over hearts and minds may be a million miles off the mark. For these types of projects the review leader should consider not only including the improvement programme manager but also representatives from the target organisation who are most affected by the change. Questions and discussions should be formulated around the human impacts of the change, not purely the technical and physical aspects of the project.

I’ve worked with several organisations where the focus of reviews was always on the tangible aspects of the project - the process descriptions and other work products. Projects that appeared healthy were in fact at risk because elements like the readiness of the organisation to embrace the change, how communications were being received, and expected levels of resistance to change were never being probed.

Here are a few of the more challenging questions that a review leader could be asking of their project managers to get a better steer on the reality of a project status rather than relying on a verbal rehash of the status report.
  • What has become clear since last we met? And less obvious?
  • What is the area that, if you made an improvement, would give you and others the greatest return on time, effort, and dollars invested? 
  • What is currently impossible to do that, if it were possible, would change everything? 
  • What are you trying to make happen in the next month, two months and three months? 
  • What's the most important decision you're facing? What's keeping you from making it? How can I help?
  • What topic are you hoping I won't bring up? 
  • What area under your responsibility are you most satisfied with? Least satisfied with? 
  • What part of your responsibilities are you avoiding right now? 
  • What one thing that I can do as your manager would most help this project?
Think about you the last review you participated in, and ask yourself how useful it was, how much value it added, and how you could improve the experience and outcomes for yourself, the project under review and the other participants. And then do it!


Monday 4 August 2014

Unifying Technical Project Management with Management of Change

One of the things that successful leaders of improvement initiatives understand is that at least 80% of the effort is about managing change. It is often something that their sponsors and supervisors also understand.

So, when you pick up a book about process improvement, you’ll generally find extensive information about understanding the psychology of change, managing resistance, winning hearts and minds and communication, and all the other ‘soft’ skills that will help you succeed. You probably won’t find a huge amount of information about writing a process. (If you think about any of the CMMI reference books there are very few pages about creating a process, although to be fair you won’t find many pages about managing change either, so maybe that’s a bad example!).

In PRINCE2 a project is “a temporary organisation that is created for the purpose of delivering one or more business products according to an agreed business case”. According to PRINCE2, projects are the means by which we introduce change into an organisation. But, pick up a book on PRINCE2 project management and you’ll hardly ever find anything about managing change, other than standard scope and change request management. What you’ll usually find are all the specific technical details about project planning, monitoring and control.


If you are creating a new product or even introducing a new off-the-shelf solution within an organisation there is a significant element of change. People will probably have to adapt their way of working. They will need to understand how the new solution integrates with existing systems and processes. They will have to understand the new expectations being forced on them through the change.

Yet, in my experience, this element of the work is rarely considered as anything other than an afterthought, and technical project managers who lead these projects are often lacking the skills required to successfully implement the change. They may deliver the product, sometimes within budget and time constraints, sometimes not, but they don’t deliver an integrated and working solution to the original problem.

The result is that staff now need to spend a considerable amount of their time trying to adapt to the change without the necessary understanding, guidance, processes and tools or even the context for why the change has occurred in the first place.

When organisations begin to understand that technical project management alone cannot meet the requirements of delivering a working solution to a problem, and learn that the end users who are closest to the work are the ultimate stakeholders, projects will continue to fail to deliver against the expectations initially set for them.

Businesses need to follow the patterns set up by change practitioners whereby technical project management skills and management of change skills are interwoven throughout the project management process, and not simply bolted on when it is already too late, or worse, ignored completely.



Monday 12 May 2014

Trying to "Implement" Lean? - Think Again!

This weekend, I spent a couple of hours reading Henrik Kniberg’s book “Lean from the Trenches - Managing Large Scale Projects with Kanban”. The book relates the author’s experience using Kanban on a large project for the Swedish national police authority. I always enjoy these kinds of true life experiences, but this one had some personal resonance for me because of my experience with Lean and Kanban in an organisation a few years ago.



I was contracting as a Quality Manager for a global Financial services organisation in western Europe and the software development department I was working in was selected as the pilot for a new Lean IT Management initiative. The development team consisted of a mixture of employees, contractors and in-sourced staff and numbered about 70 altogether. The development work was primarily feature based enhancements across a portfolio of products.

An external consultancy (a big six outfit) was brought in to lead the initiative (at enormous cost!) and a small group of internal employees were selected to be the navigators for the initiative. Their training consisted of a 5 day bootcamp and they were joined by the department head and another senior manager.

After the bootcamp there was a frenzy of workshops over the next couple of weeks. Team members were invited to participate in the workshops but had no input into the design activities which followed. Within four weeks a new set of operating procedures were “implemented” across the team. The consultants left and the department was left to fend for itself under the watchful eye of the navigators, who were effectively the blind leading the blind.

The new operating processes were a disaster. Key principles of Lean (not to mention basic change management principles) were ignored, and staff ended up doing twice as much overhead and admin work as before. Morale plummeted, confusion reigned and productivity went south.

Despite my role as quality manager, I was not engaged in any part of the process, and as such shared the despair of the staff. However, with good understanding and experience of Lean and Agile and as an experienced change leader I felt duty bound to try and do something to help resolve the situation.

I put together some notes and recommendations and spoke with the Lean IT initiative leader. He agreed with my observations and recommendations and we set about repairing some of the damage.

Which is where Henrik’s book starts to resonate with me. The most visible new process that was introduced was the daily stand-up meeting around a team white board. Ah - Kanban - you start thinking. Only this wasn’t a Kanban board or even a Scrum daily stand-up. This was a simply a highly visible (and time consuming) task and time tracking system for each team member which duplicated existing corporate time tracking tools and project schedules. The teams were given no understanding of the purpose or how the information would be used - they were just told that filling in task sheets and attending the meeting was mandatory. Not surprising then that there was almost complete resistance to the concept and the practice.



Over the next few weeks, I worked with the management, the project managers, the navigators and most importantly the team members to try to convert the activity into something more akin to a Kanban board, and to change the daily stand-up into something that could add genuine value to the projects rather than a dreaded inquisition of each team member. We succeeded, and the teams took more and more ownership of the activity by adapting it to each of their specific needs.

There were some real take aways for the management from this whole exercise:

  • Lean is not something that you implement - it is a set of principles and there are tools and techniques that can be used to support the objectives that you collectively wish to address
  • Trying to enforce change without involving the people who do the work will usually fail dismally and have significant repercussions 
  • Don’t use a Lean or Agile improvement opportunity to try and drive through personal management agendas - there is every chance they will backfire
  • Don’t let a consultant blindside you with an off-the-shelf blueprint for success. The chances are that it won’t fit your existing culture or mindset without significant tailoring and adaptation
It was a real eye opener for me to watch a very expensive initiative being undertaken without due diligence and with precious little respect for the basics of change management. It was also extremely satisfying to be able to help turn it around - and full credit to the management for realising their problems and to the staff who actually did eventually turn a sows ear into something resembling a silk purse!


Monday 28 April 2014

More Thoughts On the Value Management Office

In my previous post I outlined a proposal for a Value Management Office (VMO) to oversee many of the essential business activities needed in any reasonably sized organisation but which perhaps add no or little direct value to the customer. In lean terminology this is considered as Type I Muda.

I've spent a lot of time in organisations which obsess about things that don't add any value to the customer. In fact they detract people from doing the things that do add value, and at the same time cause folk so much angst that they start to loathe the workplace and their jobs in general. In many organisations these activities are so completely out of control (think internal project status reporting as an example) that they have spawned countless functions and roles to ensure their continuity, when the reality is that almost all these things should have been culled years ago. If you introduced many of these tasks into a start-up they'd be bust before the end of the week!

The thinking behind the VMO has come about from discussions with my partner (who works in a PMO for a major Global IT organisation) and my own experiences from both the top and bottom of the corporate food chain. It  also coincides with some recent posts from Bob Marshall, writing about 'meeting folk's needs' (The Antimatter Principle). I'm sure Bob will have issues with many of my ideas, but this is my Utopian vision, not his!



By centralising many of the functions and activities which generally take place throughout the organisation it is possible to take a holistic view of them all and make some sense out of the chaos. Instead of each part of the business (and each and every manager) building cottage industries out of things that should be simple administrative tasks the VMO oversees a single set of processes that are designed to be fit for purpose across the enterprise.

One outcome of this should be to reduce the burden to the staff who so often find themselves on the receiving end of multiple demands from multiple sources for the same information, with no idea why or how that information is being used (as indeed do few of the people demanding the information in the first place).

This in turn should allow 'managers' to focus on things that really matter, like removing obstacles rather than building them, and allow staff to get on with what they are best at - designing, building and implementing products and services to the delight of their customers.

Some organisations run a "Shared Services" function, but in my experience these groups still operate largely as silos, and only have very limited scope. This is especially true in command and control centres, where 'traditional' managers are threatened with a loss of power and control, and will set up their own systems, duplicating and undermining the shared services mandate. Additionally, shared services tend to operate 'top down' dictating to the workforce rather than collaborating with them.

With regard to changes, the VMO acts as the overseer of significant organisational change. It should not decide which changes become implemented, but act as a facilitator between multiple stakeholders, and to prevent change conflicts. It does this by bringing together subject matter experts who are nominated by the stakeholders. The VMO also acts as the guardian of good practice within the business, where individuals and teams can put forward ideas which can be shared and implemented on a wider basis.

Finally the VMO should be the custodian of organisational metrics and measurement, ensuring data is collected and used for the benefit of the whole organisation and to eliminate the need for multiple random data requests from staff.

Ultimately, the success of the VMO depends on a shared understanding of its role within the organisation and how other functions, managers and staff interact with it (and each other). This demands a level of maturity and some rethinking of the role of managers within the business which many people may find hard to accept.

But Utopia isn't going to get built without some pain, and it certainly isn't going to get built overnight.









Wednesday 23 April 2014

The PMO is Dead. Long Live the VMO (Value Management Office)!

It seems that the Project or Programme Management Office (PMO) function is 'de rigour' these days. Every search I do for Quality, Process or Change Management contracts throws up a whole bunch of PMO roles - PMO Lead, PMO Manager or PMO Analyst.

Now I've never been a PMO Manager or Lead - at least not in my official 'Job Title'. I've had much more encompassing roles, which have included most of the activities I see mentioned in these job specifications, and a whole load more. Which is probably why no-one is offering me even an interview for a PMO role...but that's another story...

I've written about PMOs in the past - often in rather unflattering terms. (Ref:PMO - Master or Servant?) Because just about all the PMOs I've encountered in recent years suffer from the same set of issues all stemming from the fact that they have either lost direction or never had a direction to lose in the first place.

I'm not even sure that the PMO name is appropriate in many cases. Because many PMOs are nothing more than management snoops and data leeches - they have become a burden to the projects rather than the supporting function they once purported to be.


The PMO isn't the only function to have fallen by the wayside. The Quality Assurance (QA) function now appears to be synonymous with Testing and is often outsourced to low cost delivery centres. Many organisations also now have a Delivery Assurance function which seems to overlap in many respects with the PMO as well as traditional Quality and Process Improvement functions but without actually delivering genuine value to the business, but acting as the compliance police, and causing additional angst to project and programmes. Many businesses now appear to be outsourcing their PMOs so they will become unseen and largely unapproachable sources of contention.

In my Utopian world I would like to see an end to the unnecessary, valueless functions (Type II Muda in lean terminology) within the organisation. I'd like to propose the Value Management Office (VMO) which has a direct reporting line to the Chief Executive with dotted reporting lines to the other C-Level executives.

The VMO is a business function, designed to oversee corporate governance, organisational change, quality, compliance and process management. The VMO is permanently staffed with a small core of Value champions to co-ordinate, act as gatekeepers and maintain continuity of the function but the ideas, requirements and solutions come from Value Action Teams from within the body of the organisation. These are virtual teams created from the people closest to the work, brought together to address real issues within their scope of expertise. This isn't a new concept - it is the way many Software Engineering Process Groups function. When objectives, roles and responsibilities and values are clearly established and shared, it is a very powerful mechanism for establishing and sustaining change in an organisation.

Above all, the VMO is a supporting function, providing genuine assistance to the wider business. VMO staff should look at every activity they are involved with and be able to clearly articulate why they are doing it, who they are doing it for, what value it brings, and whether it is genuinely a business necessity (Type I Muda or actual value add to the customer).

The VMO acts as a single conduit for all organisational change where it can evaluate the impact of change and how changes align with each other (or not) and prioritise accordingly. This helps to minimise the risk of change overwhelming the business, and the problem of multiple changes competing for the same resources.

Detractors from a central VMO approach are likely to say that this is just simply another overhead bucket with a different name. Indeed this is exactly what it could become if it is allowed to function unchecked and become another self serving and disconnected unit. Which is why it needs to be under the direct control of the highest executives within the business and why its own governance must be designed to prevent that from happening.

In future posts I'll expound on this proposition, especially about how to scale up the model to work in larger organisations. If you already have a model like this in place please share your experiences, good or bad!




Friday 21 March 2014

7 Deadly Sins of Process Improvement - eBook Now Available

I published my first article about "7 Deadly Sins of Process Improvement" way back in February 2010. Initially the idea came about as a response to a call for papers for the SEPG conference that year. The abstract only made it to "reserve" status and sadly no-one dropped out so I put it on the back burner where it has simmered over the last four years before the final instalment was served up in February of this year.

The series has proved fairly popular over the years, at least with my hardcore followers, but it is quite hard work trying to read the whole set of posts as they are separated by other random posts. So I decided to compile the eight posts and publish them as an ebook. This is partly altruistic - to make life easier for the reader, partly self-serving - I wanted to see how easy it was to produce an eBook and get it published, and partly egotistical - nothing beats seeing your own name in print!



So 7 Deadly Sins of Process Improvement is now freely available on the iBooks Store in 51 countries. You do need a Mac or an iPad to be able to download and read this version, but I am working on creating it in other formats for non-Apple users. For now though, I am happy to send out a PDF version if you send me your email address. Drop me an email at ally@allygill.co.uk with the subject "7DS Book" and I'll send you a copy within 24 hours.

I will update the publication in the future and "subscribers" will automatically get the new version.

I hope you enjoy reading the end result as much as I enjoyed creating it. Thanks for you support!




Tuesday 11 March 2014

Getting a Grip on Governance

As a programme and project manager, particularly in large matrix organisations, one of the things that used to drive me mad was the lack of joined up governance for projects. I know I'm not alone. Whenever I've been involved in organisations improvement initiatives, this is a regular bugbear across delivery.

Project managers, who are often juggling multiple projects, have to undertake a myriad of reviews, complete multiple status reports, and submit to random, often unsolicited, data requests, and run the gamut of Delivery and Quality Assurance audits. In the worst cases I've seen, an individual PMs can lose as many as 5 days a month just providing data and sitting in review meetings, often saying the same things to different groups of people (and sometimes exactly the same people!).



Now, I'm not advocating that anyone should stop performing reviews or monitoring project status. That would be a violation of lots of things I believe in, and probably commercially suicidal. But I do believe that organisations can get a lot smarter in they way they perform their governance, freeing up people's time, reducing the burden on projects, and adding genuine value to the organisation as a whole.

In a many typical organisations the project is answerable to external and internally facing governance. The client or business wants to know how their money is being spent and when they can expect delivery, and the delivery organisation needs to understand how to manage its people, IT assets and other resources. These aren't unreasonable expectations.

What's unreasonable is when the balance shifts from a need for information to help run the business to a culture of interference, where indirect stakeholders start demanding their pound of flesh. Where bean counters get notifications from monitoring systems and demand answers as to why variances are exceeded and expect solutions to be implemented by yesterday.

Quality boards and risk review boards are set-up in addition to the weekly, monthly and quarterly status review boards. Red and Amber projects find they are spending more time explaining their status than being able to fix it.
Ultimately, the project managers spend their days repeating the same things to the same people time and time again. And the majority of the people listening are not actually in a position to do anything with the things they are told, let alone provide help to the beleaguered projects.

The sticks are all sharpened ready for the kill, but there isn't a carrot in sight.

When an organisation has a systemic problem with delivery it seems that the usual way they go about fixing it is to add more and more layers of governance. It's as if talking about it often enough will make the problems go away. A smarter fix might be to review the entire governance process, streamline it and only involve people who can provide assistance and solutions, rather than add to the problem.

Joined up governance means looking at how automated monitoring systems can be used intelligently and incorporated into standard reviews. It means looking at the people who need to be involved in those reviews, what preparation needs to be done (in my experience people just turn up and fire high level standard questions at the PM), and what the expected outcomes are going to be (a completed review checklist is not a satisfactory outcome!).

This is really an ideal role for a pro-active PMO, that acts as a conduit between the relevant stakeholders and the project. Indirect stakeholders (should there still be any need for them) should be able to get information from the PMO rather than the PM. (If the relationship between the PM and the PMO becomes imbalanced, e.g. when the PMO starts to become a self serving force, this must be redressed - see my 2008 article Project Management Office - Master or Servant?).

As part of the change to governance, it's an ideal time to review the measurement systems in place. Projects are often challenged as to why data differs across different systems. The better question is why data is being captured in multiple systems in the first place as it clearly introduces scope for error - see my 2010 post When Measurement Programmes Go Viral.

Project and programme oversight shouldn't be rocket science yet many organisations have governance systems that would not look out of place in mission control. As spring starts to take hold this year maybe it's time to take a good look at your existing governance and see where it can be cleaned up, simplified and ultimately become a valuable tool rather than a weapon to be deployed against project teams doing their best to deliver real value to the business.

Friday 28 February 2014

7 Deadly Sins of Process Improvement/Change - #7 Extravagance

My final deadliest sin is that of extravagance. Extravagance is not confined to process improvement, but for many years was something of a feature of the IT industry. Extravagance has two meanings, and both are relevant in this post. The first definition refers to the lack of restraint in spending money or use of resources. The second refers to the excessive use of elaborateness in style, speech or action. Both have a similar impact on resources and money, and both can be resolved through similar management techniques.



Massive improvement programmes are still popular in large organisations. Huge budgets are set aside, an army of internal and external consultants is assembled and the senior management talk about nothing else for months. It's a matter of all hands on deck and a marketing campaign is launched resembling Kitchener's call to arms in 1914. This seems particularly true for such activities as Obtaining CMMI Level 3 or becoming ISO 9000 certified, but more recently for Becoming Agile or Lean.

Behind the frenzy of activities, old timers quietly mutter about the 'last great improvement programme' and the fact that this one won't bring any significant change after making their lives hell for the next two years. Newer members of staff, especially managers, begin to dismantle the good things that did come about from the last great change, in favour of their own pet projects and generally the whole organisation becomes a circus where each and every one of my previous deadly sins is performed in some office or corridor of power.

The problem with extravagance is that the focus of the change moves from being for the benefit of the business and shifts towards feeding egos and personal agendas.

Extravagance isn't restricted to large endeavours either. Small improvement projects can easily lose their scope and expand to fill the number of hours in the day and gobble up limited improvement dollars and staff patience.

Manifestations

Keep It Simple

The old adages are always the best ones. The larger the scope of an improvement or change programme, the greater the risk of it stepping on its own toes as one part of the programme starts undoing the good being done somewhere else - for example a project management status report being streamlined in the PM work stream whilst the management review process is being extended in the Governance work stream. Sub-optimisation is the greatest enemy of large initiatives which fail to take a holistic approach and will cancel out improvement benefits if you aren't careful.

Remember Your Audience

Most people have a limited capacity for change in any time period and over elaboration of an improvement programme will be subject to the law of diminishing returns. If your staff begin to show signs of change fatigue you need to scale back on your ambitions - but better still, show restraint in the first place and package changes into small enough packages that can be managed and implemented without overwhelming people.

Beware 'Just one more thing'

It may have worked brilliantly for Steve Jobs as a theatrical tool at Apple Keynotes but it has no place in an improvement programme. In Jobs' case the one more thing may have thrown the crowd into a frenzy, but in an improvement programme it may well be the straw that breaks the camel's back. Don't go on cramming more and more into an improvement initiative. Prioritise and move less important opportunities to later phases.

Laws to Overcome Extravagance

1st Law - Keep It Simple

2nd Law - Organisations, teams and individuals can only deal with a certain amount of simultaneous change

3rd Law - Beware the executive who begs "Indulge me" with an additional requirement after all the plans are in place



Wednesday 5 February 2014

7 Deadly Sins of Process Improvement/Change - #6 Ignorance

My penultimate deadly sin is that of Ignorance. Ignorance is purely and simply a lack of knowledge, information or understanding. Ignorance itself is not the deadly sin as clearly we are all ignorant about certain (most?) subjects. The sin is in failing to do something about rectifying your own or other's ignorance when it matters, or in pretending that you know about matters which, in reality, you are completely ignorant about. (There is an alternative definition of ignorance pertaining to rudeness, but that's beyond the scope of this particular post!)


Manifestations

Understand what you do and don't know

One only has to look at the comments associated with articles posted on the internet to see ignorance in action. Regardless of the nature of the article you will be able to find examples of comments which are clearly written by people with absolutely no knowledge or understanding of the subject. These are people who have discovered that they have a voice and are determined to use it. Occasionally I find these types of comment amusing, but mostly I'm saddened that this is the only outlet some folk have.

Much more pernicious are the comments posted in unmoderated question and answer forums, such as those on LinkedIn, where seemingly knowledgeable people are able to post misleading, incorrect or even dangerous answers to questions posed by unwary forum members. I do think that these forums have a tendency to make people lazy - it's much easier to post a question and get an assortment of answers than it is to do proper research, but at least people are asking their questions in the pursuit of knowledge (for whatever reason).

Involve the people with real knowledge

 Most dangerous of all is ignorance as practiced in the workplace by hierarchically 'superior' executives who make uninformed decisions based on their own self belief of their true abilities. This is especially the case when other staff with genuine knowledge and understanding are ignored or overruled simply because they are 'junior'.

In the specific arena of process, quality and change management there generally aren't a whole bunch of right answers (although arguably there are quite a lot of 'wrong' answers. Strategies and tactics depend on context, including the organisational culture, people and the direction of the prevailing wind. I can't begin to count the number of times I've seen ignorance presented as fact. In one engagement I put forward a number of proposals to reduce complexity and redundancy in the organisation process documentation. Almost every proposal was rejected on the grounds that "the proposal is non compliant with CMMI L3 so it can't be done". In every instance the process owner was hiding behind their ignorance of the CMMI without understanding the guiding principles of the model. After a bit of coaching, and some learning moments 95% of the recommendations were accepted as proposed, and the remainder accepted with some rewording.

I hope I never stop learning and relearning. Understanding new ideas and concepts is key to developing better outcomes for clients (and myself). Sometimes our own understanding of existing ideas and concepts need rethinking and alternative viewpoints. And the day I give someone advice based on something I know nothing about... is the day to quit.

Laws to Overcome Ignorance

1st Law - Be on the constant lookout for new ideas, concepts and tools to help you see a bigger picture

2nd Law - Never stop learning and encourage others to do the same

3rd Law - Challenge ignorance wherever it manifests itself as false knowledge and fact

Wednesday 22 January 2014

Fanning the Flame Wars - Scrum vs Kanban?

Thirty years ago the longest running war in IT broke out and it's still going on today - Apple vs PC. Since then a multitude of other wars have broken out, many of which are also still being fought out today, mainly across the pages of the internet. These include (but there are countless more) :

  • BASIC vs Pascal
  • iOS vs Android
  • OS X vs Windows
  • Rumbaugh vs Jacobsen
  • Agile vs Waterfall
  • PMI vs Prince 2
  • Apple vs Samsung
  • Lean vs Six Sigma
  • SSADM vs OMT
  • CMMI vs SPICE
  • ITIL vs ISO 20000

Without exception, they are meaningless, no-win wars which do little more than misdirect web traffic to meaningless articles and often spurious arguments in favour of one or other protagonist (and yes...I'm well aware that my headline is guilty of just that!). They also draw attention away from the real issue of helping to improve the way that work can be done.

The latest war that I'm aware of (based primarily on my Twitter feed) is the Scrum vs Kanban feud.



I don't want to go into details of either of these concepts in this (or any future) post. Needless to say, I am very familiar with both 'tools' and have a good understanding of their relative strengths and weaknesses. More importantly I fail to see why they need to be mutually exclusive - why I have to have one or the other. In fact, the same goes for just about every pairing in the list above.

As an advocate of process management, I want access to the best set of ideas and concepts available and to be able to use my judgement to string together a set of modules that is best suited to solving the problem at hand, in the specific environment that I'm working in, and relative to the business needs of my client.

If I go out promoting a single service, method or tool, to the exclusion of others, I am doing everybody a massive disservice. I see part of my role as an integrator, continuously integrating new and existing techniques and ideas into my personal process management toolkit, so that my clients can focus on the things that are important to them.

Flame wars have no place in the professional world. They should be left to the people who have found their voices on the anonymous world of the internet, but who haven't yet learnt that just because you can say something, it doesn't mean that you should!



Friday 17 January 2014

Redundancy - the Ultimate People Process

In 2006 I was made redundant for the first (and last) time. At the time I was  devastated, not least because I was completely blindsided by the decision. Just a few weeks previously I had my annual performance review at which I "Far exceeded expectations", received a 5% bonus and a 10% pay rise. At that time bonuses were far rarer than rocking horse droppings and pay increases were 0% to 1.5% with the former being the standard. Needless to say I felt that my star was on the ascendent.

A month later I was called in to a meeting and given the news that my services were no longer required. A settlement package was on the table as part of a compromise agreement which I was expected to contest under the advice of a solicitor. There was no appeal, it was a done deal other than the extent of the final renumeration.

It turned out that I was in good company - a large number of my colleagues in the European leadership team were attending similar meetings during the course of that week. That didn't make it any easier, but at least for all of us the axe was sharp, the executions swift, and the journey to the next world was short. In hindsight, this was a fantastic opportunity. I sprinted through the psychological change curve which I had lectured about on so many occasions and started building my new life, and decided that no-one was ever going to get the chance to put me through that process again. (As an aside, it turned out that the architect of the executions lasted only a few weeks before signing out himself, apparently stressed out and sick from wielding such a heavy axe!)



The process of redundancy continues in unparalleled numbers in the organisation to this day (although it now exists as a division in a larger business). 34,000 people will lose their jobs this year alone. They are not as lucky as I was. They are being toyed with, by managers who seem to have little idea of the torment they are causing the individuals and little understanding of how much damage they are doing to their business, their bottom lines and ultimately their clients.

There is a massive hiatus in productivity as groups of people meet to discuss their fates. People are receiving "at risk" letters, months before decisions are being made about where actual jobs are being lost. Staff are placed into pools of potential redundancies and being told that they have 100% chance of losing their jobs only to be reprieved at the last moment because there is too much work on the books for a reduced work force to cope with. Experienced domain experts are expected to hand over to new graduates who are then expected to continue to provide the same level of support. And in an attempt to "invert the management pyramid" the real outcome has been to take out fewer managers than ever at the expense of genuine value add staff.

I've long been a believer that cutting jobs is about the daftest way to try and cut costs, and that a pure focus on cutting costs is the daftest way to try and improve performance, efficiency and effectiveness. To run a redundancy programme that is so devoid of common business sense that it is reducing output and productivity without actually adding any value whatsoever is the daftest thing of all.

If you must make people redundant, do it with respect, sensitivity and empathy for your staff. They are not human resources, they are the people who helped put you where you are. If you can't recognise that, then you don't deserve to share the same space or air as them. And don't be surprised if they take their loyalty elsewhere - or is that what you were really trying to do? Make them so unhappy that they'll leave without you having to pay them off? Just remember, what goes around, comes around...