Projects plow (or plod) ahead just fine, especially when there is something that is believed to approximate a charter, like a project or work initiation document, a sensible budget spreadsheet, or a darn good powerpoint presentation. What could possibly go wrong when a group of managing directors get together to approve a large project on the back of a budget and a presentation? Probably little will go wrong that day.
Imagine an IT project that burns through most of a 9-digit budget in about 18 months only to find that the completed product could not be used by its intended users. Imagine the rest of the budget and roughly another six months were then spent adding essential functionality. Imagine the finished product was ultimately used by a single person, whose job it was to export the data to Excel every day for all the other users.
One thing that project managers are constantly being tempted to do is to unilaterally move (or re-interpret) the project objectives, boundary, committed resources and authorizing players (as described by III in his chartering article). When these are not agreed before the start of the project or do not have to be reviewed during its execution, there is always the risk that work will conveniently be moved out of the project.
In the above example, a more junior manager working on smaller projects for the same business spotted the project objectives changing (and the consequences) about 12 months in. When the senior PM was offered evidence that his project would no longer meet the needs of the business, he confidently defended the project on the grounds that it had the blessing of 11 managing directors and that all was well.
Information is never perfect or complete, so I would reinforce that the project charter needs to be continuously validated and consciously lived up to. For example, the end of an iteration or a release should highlight its contributions to the charter objectives; a prototype demo should produce minutes with feedback from the authorizing players; status reporting should include the realized value that the work so far has delivered, as well as the amount of unrealized value that has been accumulated (and is therefore at risk) - all in the context of the charter.
There are a number of highly toxic traps that a project can find itself in. It could be that the project is perpetually spinning with no defined end. Perhaps it is being (ab)used to further or encumber someone’s advancement in the organization. Some projects are completed with an anecdotal pronouncement of success that - just like the emperor with no clothes - has no substance and yet no-one challenges it. Others successfully deliver what was required last year with little or no attention paid to what was required of the project since. One of my favorite stories is a project on which the top stakeholder expressed the strongest resistance to measuring the impact of the flagship IT project to his business line over the course of several releases. His preference was that after the project was implemented someone should come up with measures to publicize the extent of success.
If I may borrow just one quote from the article in this short post, it has to be:
“If there is major difficulty in forming and agreeing on a Charter, imagine the grief that would emerge from plowing ahead anyway.”
Going forward I would like to write about my conversations with III as I try to educate myself on specific aspects of chartering. Keeping to the overall theme of this blog, I would specifically like to explore chartering at the enterprise level. This will include scaling the chartering process, addressing its communication and adoption throughout the organization, visibly and measurably linking it to the chartering of individual projects, and using it as a feedback loop to help make the enterprise more adaptive.
A while back, I had the opportunity to hear Mary Poppendieck speak at the BayAPLN. I just spotted the Agile 2007 90min video+slides version of it and had to watch it again. Of particular interest to me were the case studies. I was already aware of the Toyota Production System, how it focuses managers on coaching and on leveraging the combined intellect of the employees. This approach is in contrast to decision-making by decree. Toyota is also known, like Dell and a few others, for using a “pull” process – your car or computer won’t be built until you’ve requested and paid for it.
Fashion retailer Zara, was a new case study for me. About 61min into the video (slide 29) Mary summarizes what Zara doesn’t optimize for in order to attract their customers. Shipping costs and labor costs are high, while lot sizes and inventory are low. Traditional fashion retailers optimize all these in the opposite direction! To learn what they do optimize for and a little more about their business model I went to the press dossier and corporate report for INDITEX, the holding company. One section in particular stood out for me:
“The feed-back of the store staff to the commercial team is fundamental to the process of creation and design of the collections which each of the concepts in the Group launches. This contribution is simply the interpretation of the desires, comments and individual opinions of our customers by fashion specialists who are in direct contact with the market.
For this reason, the training of the store staff has two of its fundamental axes in giving them a specialised knowledge of the evolution of trends in fashion and, on the other hand, in the capacity to take in and to formalise the information which is supplied to them every day by the customers all over the world.”
– INDITEX annual report 2006, pg 30
Wait. *double-take* They train their staff in fashion trends and to collect and formally communicate the feedback from customers? The people they hire are probably just as smart as those working for the competition, but at INDITEX they are expected and trained to think - and listened to - not treated like automatons. This feedback loop truly puts the customer first, and leverages the collective intellect of the employees. They consciously avoid the sort of optimization applied by their competitors and strive to make the whole enterprise into a massive self-optimizing engine. Their results are impressive in isolation and astonishing next to their competitors’.
Compare and contrast with companies you have worked for. Are you entrusted, educated, encouraged and empowered to make daily contributions to the optimization of the enterprise? Do you at least have the correct incentives and measures to determine how your decisions align with the objectives of the enterprise? Hmm. Perhaps there are mechanisms in place to avoid different departments getting in each other’s way? Surely you have at least a suggestion box that and management reviews it frequently to show that your opinion, ideas and intellect count? Oh? Oh dear.
Perhaps you like so many of us have mostly worked at one of those places where the distribution manager has the incentive to minimize shipping costs. Every other department manager optimizes locally for their domain of control because that is what they are personally accountable for and they have little or no context of the enterprise anyway. The lifts in your building are probably optimized (with a fancy touch-panel) to minimize maintenance and wear-and-tear, rather than to minimize valuable employee or client transit time.
Enterprise optimization is not an afterthought. It must be built-in.
PS: I have added these related books to my personal reading list:
Companies can sometimes be pretty indiscriminate with their policies and decisions. I’m all for the pursuit of the greater good but I feel this is sometimes confused for the pursuit of a one-size-fits-all. Decrees can be very useful last-resorts to get an organization to take needed action or to implement new legislation. However a common consequence is an impact on the connection the employees have with the enterprise health and objectives.
Consider medical treatments that knowingly but necessarily put the patient’s life at serious risk. Everything must be done to increase the patient’s chances of survival, and vital signs must be monitored very closely for indications that the treatment might need to be stopped and changed altogether. An enterprise should take this approach as well. When the only sensible course of action available is a decree, make sure that you create way more feedback loops in your organization than normal. They increase your organization’s chances of survival, increase the likelihood of success of your policy, and behave as your self-monitoring system. Listen to those early-warning signals and visibly adapt your policy and/or implementation strategy from what you learn. This is not a license to manage your enterprise via decrees, just a suggestion on how you might avoid total disaster when and if you have no other option but to implement a decision in this way.
A few years ago I was particularly aware of contractor tenure policies being a high-profile issue in the US. This led to global policy rollouts despite legislation in other countries being in place to clearly differentiate between employees and contractors. Companies that had no monitoring systems for this decree probably failed to detect that the contractor litigation risk was significantly smaller in other countries. In the UK for example a nationwide organized contractor population has been reducing this risk to virtual nonexistence in order to protect themselves from tax legislation IR35. In these cases, big companies that were trying to minimize risk in the US indiscriminately and unnecessarily removed UK-based contractors even from key projects thereby shooting themselves in the foot. And leg. Repeatedly.
As we describe a management methodology for the enterprise, we are going to need to explore a number of approaches for adoption. A type of guidance I really appreciate is when others share their practical experience over time. Salesforce.com is one such example. They took the Big-Bang approach to their adoption of agile principles and methodologies within IT and throughout the process they have spoken about their progress often. Steve Greene and Chris Fry will be presenting an update on the experience at the July 15 event of the Bay Area Agile Project Leadership Network. For more information go to BayAPLN.org and be sure to use the rsvp link if you want to attend.
One often gets to read or hear about such initiatives and their promises early on in the process but thanks to Steve and Chris (and no doubt other colleagues) their story has been updated and made available to a wide audience. “The Year of Living Dangerously” (slides also below) is the latest update on their journey. Another valuable read for me was the experience report they shared at Agile 2007 on “Large Scale Agile Transformation in an On-Demand World”. At the time, they were reporting on completing a “three month transformation” but on the 15th you might be forgiven for asking in hindsight how much of the transformation was still ahead of them.
Apparently they have started to talk about how agile principles and methods could be used in all departments of the enterprise - not just IT. Naturally, they have my full attention.
Reward and incentive structures are often designed around the performance results that are relevant to the business of the enterprise. One reason for this is that everyone can see and easily measure the bottom line. While this will often be a necessary input, it is nowhere near sufficient to result in high levels of productivity. My own test for this is to ask teams and whole organizations within the enterprise what would make them more productive or likely to meet the stated targets. I would be surprised if any of them responded that more money would make any difference to their productivity.
Another popular approach is to measure by accountability and individual results. The hope here is that by making each senior manager accountable for something specific, they will ensure that their teams use everything at their disposal to fulfill those targets. The process is then repeated until each person in the organization is accountable for something. How can we then be surprised by the “management trap” where the last manager in the chain micromanages their team’s activities and even assigns and tracks tasks to the atomic level? Since everyone is focused and every task has an owner, this should result in the goals of the enterprise being delivered in the most productive manner, right?
In such an environment, helping others to achieve their targets becomes unnatural behavior since this can only be done at the expense of delivering the results that you are personally accountable for. Even with the best intentions, there is a barrier to the help that an individual can provide, since only the person accountable really knows enough about the work to continue doing it. The same is true for teams or departments, which is why they often operate in silos.
One of my former teams was suffering badly from this when I joined. Each developer was responsible for the delivery of one or more projects, each varying in effort between 3 and 12 months. Everyone knew which developer had the most critical or toughest project – or in this case both. They were each secretly glad they were not him. To make things worse, his knowledge of the application and phenomenal design and coding skills meant he was constantly redirected to small urgent projects or involved in complex support issues. Despite occasional short contributions from the rest of the team, the result was a perpetual delay of that project - and the rest were also faring badly. The team decided to self-organize around the main projects, thereby putting our own individual objectives at risk and potentially facing disciplinary action - I was personally referred to HR for this. We all spent the next two weeks pairing with and learning from our friend everything there was to know about the top project. During the following three weeks the team made the first delivery on it in nine months.
The issue, I believe, is at the enterprise level rather than at any one of the management levels a team reports into. I agree with those who suggest that the prevalent need of the individuals we work with is not to be told what to do or how to do it. For us the critical step was to work together to define these as a team. As our team evolved, we defined the behavior we thought was “right”, that we wanted to see in ourselves and wanted others to identify looking in on our daily work. One of these took the form of a team principle:
We value the productivity of others above our own.
This turned out to be one of the strongest accelerating factors on our productivity. If you think this simple assertion might be the right thing to do in your work, feel free to apply it. Gather your teams to discuss what behavior would help them increase productivity and to define guiding principles for themselves. Turn those into department or enterprise guiding principles so everyone uses them when making his or her own daily decisions. At the same time, soften the stance on individual accountability or task-assignment. I’m interested in hearing about your own experience with this.
In this blog I am keen to explore the next stage: how to measure and foster the behavior that is embodied by such enterprise guiding principles.
In engineering I learned about how Adaptive Control is used to manage Nonlinear Processes. These are defined as processes that change in behavior as operating levels change. An example might be an industrial plant where chemicals, gasses, liquids and other things are mixed together at a constant rate but at some point the temperature of the mix starts to increase and even accelerate. With the right mechanisms in place the plant will adapt accordingly and sustain its performance. The adaptive control systems that manage such processes use highly tuned feedback loops and signal filters to drive sophisticated control valves and keep the plant from exploding. If you are technically inclined, here is a technical chapter on the topic.
This blog explores how many of the companies we work at also display nonlinear behavior - and at times potentially explosive behavior - but are often managed using simple linear management techniques. If so, when the company’s “temperature” starts to rise and performance starts to drop nobody notices. This is aggravated when the change follows more of a “slow boiling frog” pattern, and I suspect this is quite common. How many of us have seen teams suddenly disintegrate? People are generally resilient, understanding and accommodating so it is possible that the sudden exodus event was in fact the result of many factors over a significant period of time. With your help, I would like to define Adaptive Enterprise Management as a methodology and validate the hypothesis that it can improve the performance of any size of enterprise.
In her presentation she addressed the question of how to hire and promote The Right People. She summarized these views expressed by Dee Hock, Founder and CEO Emeritus of VISA International:
“Hire and promote first on the basis of integrity; second, motivation; third, capacity; fourth, understanding; fifth, knowledge; and last and least, experience. Without integrity, motivation is dangerous; without motivation, capacity is impotent; without capacity, understanding is limited; without understanding, knowledge is meaningless; without knowledge, experience is blind. Experience is easy to provide and quickly put to good use by people with all the other qualities.”
It is possible that that Mr Hock was referring to finding business associates, rather than staff, but nevertheless I like and associate with the romantic notion he describes. My daydreaming of an enterprise that followed these principles must have lasted for all of ten seconds, or the time it took Pollyanna to list them. I came crashing down in a ball of self-righteous fire when someone at the back of the room, likely David Anderson, pointed out that hiring on anything other than ability to perform a job would be legal quicksand.
<dream>One day I may get the chance to experience working at VISA and test for myself what it feels to be in such an environment</dream>
If you are intrigued, you can read about Dee Hock’s views on management here.
No sooner have I activated this blog than I already have a practical example of where Adaptive Enterprise Management might make a difference. Denis Brégeon describes his surprise at the management trap he recently found himself in. As a team member, you can call out all the things you wish managers did differently. However when you’re asked to fill those shoes it is amazing how difficult it is to behave any differently, even if for just three weeks.
The intention to do the right thing is a necessary but I’m afraid not sufficient condition to bring about change. The order in which you make the changes is also important, which is what I think Denis was being confronted with. For his team to work as self-organizing peers, there has to be collective accountability. In order to remove (or at least minimize) the sense of personal accountability within the team, the team has to be rewarded before the individual. Changing the reward structure is an enterprise-level decision.
Despite this logical sequence, I know there are teams out there that achieve this change. Does it happen more often in settings where the work of the team is a more significant part of the company’s profit? Is it easier when the project or the company is smaller so the team has a bigger say in enterprise decisions? Is it better to try on a project “below the radar” first? I would like to read your views on this but right now I don’t think so. In future posts I will explore how one of my former teams achieved this result within a very big company and whilst delivering a very high-profile project.
Welcome to the Non-Linear Enterprise blog. While its charter is being developed, here are at least three aims that motivate the start of this journey.
The first is to satisfy my thirst for knowledge and that of those who come upon it, for whom I hope to make this a useful and regular virtual thinking lounge. A strong focus of the blog will be on the principles and methods that might help address the non-linear nature of the corporate world we live and work in. I will shortly be writing a few posts to define what I mean by a non-linear enterprise.
The second is to explore opportunities to increase the adoption of Agile methods. The approach here will be to try to address the scalability issues that understandably hold back many senior managers and executives from endorsing and adopting them.
The third is to provide a supportive environment for those who would like to get better at sharing new ideas. I am keen to bring my own ideas to the largest possible audience that can use them. Perhaps many of you can relate to this, e.g. either with frustration at not having taken the necessary steps after any of your many a-ha moments, or with experience after building successful start-ups from your (and others’) ideas.
Since I don’t have all the answers, none of this will be possible on my own. Your input and feedback will make all the difference.
Loading ...
