Is it Agile Decision-making? Or Inadequate Planning?
Even in a well run organization, it may be necessary to cancel a project in response to new information. A new competitor may have already introduced a game-changing product. Market pricing may have changed, making a new product economically infeasible. It may be necessary to reduce capital outlays to keep the business afloat. Cancelling a project under these conditions may be a great example of agile decision making. But it could also be a sign of inadequate planning.
Whenever a decision is made to cancel a project, it is worth taking some time to reflect on the project and ask a few questions:
- What were the flaws in the original planning premises?
- Do these flaws indicate shortcomings with access to market intelligence?
- Was the project clearly tied to a strategic objective?
- If the project was tied to a strategic objective, should that objective be evaluated?
- How was the decision made to launch the project?
- Would there have been a different outcome with a different project team?
Cancelling a project is a very painful decision and it is human nature to want to move on quickly. An agile leader must ensure that the organization first learns from the pain, and then moves on.
What is the cost of “no surprises?”
Early in my management career, I reported to a politically savvy executive who insisted on “no surprises” from his direct reports. He wanted to make sure that he would always be able to respond to questions about any of our projects and thus avoid the appearance of being out of touch. Since then, I have met managers who either explicitly or implicitly expected the same. Some would become angry with their direct reports any time they were presented with questions for which they were unprepared.
Beyond exhibiting insecurity, these managers are increasing costs for their employers. Their direct reports waste time on frequent and sometimes detailed emails on day-to-day problems and issues. Meeting time is devoted to bringing the boss up to speed and PowerPoint presentations are developed to ensure the manager is properly briefed.
Managers who want no surprises are focused on control rather than empowerment. They demonstrate that do not trust their direct reports to make decisions themselves. As a result, they inflict a level of organizational paralysis.
In a fast moving organization, managers look for ways to remove obstacles for their teams rather than control their actions. For such an organization, the cost of no surprises is the loss of agility.
The Trouble with Flat
When designing the structure for an agile organization, flatter is better. A flat organization can speed decision-making, limit time wasted on turf battles, and adapt more quickly to changes. There is one problem with flat organizations – they may limit the career aspirations of your best employees.
In the April 2011 edition of Inc. magazine, Jason Fried writes about a recent situation at his software firm, 37signals. One of Fried’s best employees left because she wanted to move into management and 37signals has no managers among its 27 employees. Fried did not want to begin to introduce layers of management, so they parted ways.
To limit attrition of your star employees, start during the hiring process. Make sure the potential new hire understands that there are limited opportunities to move into management. Design your compensation structure to allow your employees to grow their income while remaining on a technical career path. Provide a considerable level of autonomy to your best technical staff. Finally, get comfortable with the idea that, no matter what you do, you will occasionally lose a star employee.
When your boss is a micromanager
When interviewing I.T. professionals, I often ask them to describe both the best managers and the worst managers they have worked for. The description of the worst managers invariably fits the profile of a micromanager. The behaviors attributed to these managers including 8 am “bunk checks,” monitoring emails, and demanding pre-approval of the most mundane decisions and communications. Beyond the excessive need for control, these managers tend to use insulting or demeaning language. Some are even described as “screamers.”
If you report to such a manager, your first choice might be to find another job. Failing that, you will need to adapt to life with a difficult boss. A good place to start is to ask him the question, “What information do you need from me in order to do your job?” Use this conversation as a means to negotiate expectations for status reporting and other communications. As your boss thinks through what he needs, he may become a bit more realistic. Once you reach an understanding, make sure to live up to your end of the agreement. If you fail to do so, you will invite an even greater level of scrutiny.
If your manager is also a screamer, you have a more difficult problem. You will need to maintain your composure and demonstrate a higher level of professionalism than your boss. If you receive a flaming email, do not respond in kind. Simply reply with three words, “Please call me.” When your boss calls, try to address the concern directly and avoid being emotional. If your boss is screaming at you in person, point out his level of emotion and offer to resume the discussion later. Then leave the room.
Be very careful about escalating your concerns to your manager’s manager. While you may get some assistance, there is a good chance that he is also aware of the behavior and is unwilling or unable to correct it. Bear in mind that you cannot change your boss’ personality. Instead, you need to adapt your own behavior and actions until you can complete your exit plan.
What we have here is a failure to collaborate
The authors of the “Manifesto for Agile Software Development” (www.agilemanifesto.org) note that they value:
- “Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan”
While these values are easy to understand and appreciate, they are very difficult to implement because they require extensive collaboration. The leaders of most established companies built their careers in cultures that value control, predictability, and a healthy dose of “CYA.” While they may desire innovation and appreciate the sound of the word “collaboration,” they unwittingly erect barriers to collaboration. Some of those barriers are apparent but others are move are more subtle. Here are a few examples:
- People with roles that have the sole purpose of “gatekeeping”
- Organization structures with too many line managers
- Excessive inter-departmental rivalry
- Information security guidelines that limit the ability to share documents with external customers
- Office floor plans that limit the ability of team members to work together on an ad hoc basis
Agility requires collaboration, and collaboration requires a supportive climate. An agile leader must cultivate such a climate by eliminating barriers to collaboration.
Lessons Learned Meetings and the Confessional
The lessons learned meeting at the end of a project is a perfect opportunity for incremental improvement. But that opportunity is lost because of the dynamics of the meeting. Team members who are conflict-averse will hesitate to say anything that will offend. By contrast, the hyper-critical team members will go out of their way to ensure everyone is offended. Here is a suggestion for improving your next lessons learned meeting.
Many years ago, my parish priest introduced a sermon by saying, “Ladies, when in the confessional, please limit your confession to your own sins and do not confess those of your husband.” I have often applied this to the lessons learned meeting by asking all participants to come prepared to report three things that they would like to do differently on the next project. This will reduce the feeling of conflict and will provide some great ideas for improvement. Confession is, indeed, good for the soul.
Cultivating a culture of trust
Reflect on someone that you trust completely. You are confident that person will look out for your best interest or will meet his commitments. Now think about your co-workers. Do most of them meet that description? Conversely, how would they assess your trustworthiness? High performance, agile organizations require a high level of trust, and those of us in a leadership position must cultivate a culture of trust. Here are three tips for doing so.
Bury the hatchet
It is not possible to hold a grudge and simultaneously trust the person who is the object of the grudge. As leaders, we need to discipline ourselves to let go of animosity and instead focus on the work to be accomplished. Further, we need to coach everyone on our teams to do the same.
Turn off the email flame-thrower
Flaming emails are a sure sign of a low-trust environment. If you feel the need to correct or admonish someone, do it in person rather than sending an email with a broad “cc” list. If you are copied on such an exchange by someone on your team, have a word (not an email) with the sender and coach him on proper email etiquette.
Make commitments and then meet them
Your customers, co-workers, and team members rely on information from you in order to do their jobs. When asked to provide some information or a deliverable, don’t just say, “I’ll get it to you.” Instead, say, “I’ll get send it to you at Tuesday afternoon at 2 pm,” then do it. Make it a habit to set expectations and then meet them. Before long, others will learn to trust you to get the job done.
Trust – a prerequisite for agility
Organizational agility requires a high degree of trust. Decisions must be made quickly, which requires authority to be delegated to the level at which the relevant knowledge exists. Communication must flow freely among workgroups, without a great deal of filtering. Team members must trust that, when a particular deliverable is produced, it has been adequately tested and reviewed.
In the absence of trust, organizations substitute extensive requirements documents, excessively detailed test plans, and exhaustive procedure guides. These ancillary documents may be viewed as more important than the final products. While some documentation is necessary to facilitate communication and ensure auditability, much of it serves no purpose other than to defend against potential criticism. However, excessive documentation is not the problem. It is merely one symptom of a low-trust organization. Other symptoms include hyper-critical managers, unnecessary escalation of decisions, and internecine battles among departments.
A low-trust organization cannot be improved by team-building workshops, motivational posters, or personality profiles. The lack of trust is a direct result of the behavior of the leaders of the organization, and only the leaders can change that. Until they do so, the organization will never achieve agility.
Don’t let a good issue go bad
Issue management is the lifeblood of project management. With effective issue management, project managers can employ their listening and negotiating skills to help the team avoid obstacles and prevent long-term problems. Ideally, issues should be resolved at the team level and escalation should be employed only when other measures prove unsuccessful.
All too frequently, project team members undermine effective issue resolution processes, and they do so with the assistance of senior management. Here’s how it works. John is assigned by Ann, his VP, to work on a project team. John observes a potential problem with the project and raises his concern to Ann. Ann is surprised about this problem, and expresses her disappointment to Tom’s boss, Frank. Frank calls Tom into his office and demands an explanation as to why he has allowed this problem to linger. Tom now needs to work with three people to resolve an issue that could have been handled quickly had it been dealt with directly. Tom also must stifle his urge to choke John.
Once the issue is resolved, Tom should use this as a “teachable moment” for his boss, Frank. He should counsel Frank that when issues are escalated in the future, he should ask the “escalator” what steps have been taken to resolve the issue at the team level with the project manager. Unless there is evidence that the issue cannot be solved with the project manager, Frank should send the escalator packing.
Why do executives allow improper issue escalation? Perhaps they do not receive enough short-term gratification by doing their own jobs. They enjoy going home at the end of the day feeling that they accomplished something by fixing another mess. Of course, they ignore the fact that they have just set the stage for future messes.
Becoming both a quitter and a winner
Agile organizations must be prepared to adapt quickly to changes in the market. To pursue a new opportunity, they must be willing to re-deploy scarce resources by abandoning a product, service or activity that already exists. The decision to abandon is painful and is typically delayed far too long, thus depriving the new opportunity of resources.
In his book, Management Challenges for the 21st Century, the late Peter Drucker proposed that abandonment decisions must be practiced systematically. Drucker described an outsourcing firm that scheduled abandonment meetings on the first Monday of every month. At each these meetings, all levels of management complete a comprehensive review of one aspect of the business and identify what should be changed or abandoned. Twice a year, all levels of management must report on the actions taken as a result of these meetings.
Without a formal review process, unnecessary work and unprofitable business will drain resources and impede progress. If you periodically review your operations, you will find projects that should be canceled, services that are no longer profitable, and reports that no one reads. Such work should be identified and eliminated. Your competitive edge could very well result from the work you don’t do.
