The annual NASA PM Challenge is a really good meeting. The speakers are generally excellent and the material covers a wide range from project management fundamentals to the latest great and innovative management ideas. The ratio of outstanding talks to duds is excellent at this conference. Following up on my last post about Norm Smith’s talk at this meeting, here are some additional random ideas, lessons, and thoughts I noted from various talks at the conference:
Be wary of SPI: it does not care if the work performed was on critical path or non-critical path items. Your project may be more or less on track than SPI indicates.
For typical projects, CPI does not change significantly after 20-30% of project completion. If the CPI is not good at that point, significant intervention is likely needed to correct it.
Good PM risk reduction technique: ask “If I gave you some $, what risks could you reduce for how much?”
Listen to learn.
Think “I get to” vs. “I have to”.
Contracts need to acknowledge and provide for iterative and collaborative risk management.
Contracts should support and provide for strategic as well as tactical collaboration.
How many technical innovations from the past 20 years do you use daily? How many management innovations from the past 20 years do you use daily?
Sometimes you have to cast away past successes to reach new ones.
No one comes to work wanting to do a bad job.
Adapt to your team, not v/v.
Starting a new online platform? Seed it with content before going live. People won’t come back if there’s no point the first (few) visit(s).
Take your job seriously; don’t take yourself seriously.
Project Management 101 teaches the need to actively, and simultaneously, monitor and manage a project’s cost, schedule, and scope. Project Management 102 might add risk management to the list as well. These ideas have become fundamental tenets of project management and have been around for decades, yet projects still fail. Are project managers simply not learning these lessons and not actively managing this crucial project management trinity? Or, perhaps, is there something more that’s needed?
I certainly agree that a project must manage its cost, schedule and scope. I’ve even written about the importance of doing so, but this alone, as countless delayed, over-budget, and failed project have told us, is not enough to ensure project success. A project must first be addressing the right issue. Is the result of the project what is needed? A project also needs a project sponsor who can provide support when needed and work internal and external stakeholders to develop a consensus for and enthusiasm about the project. Additionally, a project needs overall stakeholder involvement and buy-in. And finally, a project needs good change management. Change will happen; it’s how it is handled that can make or break a project. Without properly addressing these items – project purpose, sponsor and stakeholder involvement, and change management – even proper managing of cost, schedule, scope and risk will likely still result in a failed project.
Norm Smith, in a recent talk I attended, (you can read more about Norm Smith and his ideas at his website: http://www.smithops.com/Training.php; I definitely recommend watching Norm’s brief video via that link), broke this list down (and improved it) as:
Situational Awareness
Enfranchisement
Boundary Maintenance
Situational Awareness is understanding where you are in the project, where you started, and where you are going. Schedules and project plans are often the tool used to create this awareness, but they don’t always work for that purpose and they are often used more as a means to themselves, and not as a tool designed solely for situational awareness. Norm stressed the importance of using a schedule to the detail needed to provide the right amount of situational awareness. You don’t always need each work package broken into half-day tasks to successfully manage a project and maintain situational awareness.
Enfranchisement is fairly simple – getting your team and stakeholders (including the project sponsor, which I had separated out, above) united in the project mission. This task is crucial if you are to efficiently deliver the right products and overcome unexpected surprises thrown at you along the way.
Boundary maintenance is akin to scope management and change control. It is making sure the project does what it is supposed to do, not more, not less. It is also responding appropriately to the change which is inevitable for most projects.
In this new light, managing cost (ex., Earned Value Accounting), schedule (ex. Work Breakdown Structures, Microsoft Project), and scope are simply tools used to create the situational awareness and boundary maintenance that are the real core components necessary for a successful project. Don’t let these tools control the project. They are not the essential tools for a successful project; they are simply tools, and not the only ones available at that, that may help you create the real elements needed for project success.
If you’re interested in project management, especially as it pertains to large projects, Scot highly recommends the annual NASA Project Management Challenge meetings. Some of the best talks he’s ever heard have been at these meetings.
Change Management is a idiom often heard these days where I work. I’m sure you know what it refers to – the process of implementing change in an organization and converting employee’s initial reactions of fear/anger/doubt to ones of discovery/understanding and ownership. The management steps used in this process involve opening up the avenues of communication to explain why the change is being made, providing training as needed, dealing with resistance, aligning employee and company needs, obtaining buy-in, implementing, and repeating – or some variations thereof.
I never bought into this approach and have recently figured out why. First off, it starts the communication and gathering of input process too late – only after the decision has been made. In reality, employees should be part of the problem formulation and solution formation from the start and not only after the powers above have declared some particular change is needed. My second objection is more fundamental in that this approach espouses certain kinds of activities and communication approaches only during major change, when in reality the proper change management approach is simply a good every day management approach. Since the default is to do today whatever you did yesterday, nearly every decision made represents some kind of change. Why do we worry about communicating with employees, aligning needs and strategies, and getting buy-in only when we see some decision as part of a change management process and not otherwise? It just doesn’t make sense. Good communication and employee involvement make good management sense always – whether or not the company is going through a major change.
It is not so much that the basic change management approach gets it wrong (and I’m sure some change management proponents adopt more sophisticated approaches which solve my implementation objections), it is more that it implies you need to worry about good management practices only during a big change and not otherwise. It is this implicit tolerance of bad management practices being the norm that I find the most troublesome and fundamentally bad for the organization. Good change management is simply good management. It doesn’t need to be separated into its own discipline.
By all means, communicate with employees, get their opinions, align their needs with those of the company, and monitor the implementation of new projects, but do this early and do it al the time! Manage this way and you’ll never have to talk about the change cycle or change management again.
Although not a particular fan of the “change management” dogma outlined above, Scot does believe in the Systems/Software Engineering approach to change control in projects. His life changed significantly for the better when he discovered CVS/SVN, for example, which he now uses extensively for his personal projects, both software and written.
Somewhat recently, I finished reading Employees First, Customers Second by Vineet Nayar. It was a very easy read since the techniques the author talks about using to restore his company to an industry leader agree a lot with what I already believe. Nayar makes a strong case, based on real experimentation and use, for complete transparency, honest confrontations with the truth of what problems and potential problems lay ahead, freedom of information, and making management accountable to employees and not just the other way around.
Early on in his tenure as CEO, Nayar realized his company had slowly gotten used to being at the top, satisfied with slow, steady improvement rather than large leaps of innovation. Nayar writes: [My company] had lost its competitive edge because it had become tolerant of gradual change … and unless the company becomes obsessed with constant change for the better, gradual changes for the worse usually goes un-noticed. He also realized the solution to the company’s problems, even awareness of the problems themselves, laid within the employees, not necessarily with the managers at the top of the traditional hierarchical structure.
In his introductory meetings with employees, Nayar realized there were three broad-types of employees: the transformers who understood and wanted to make things happen, although they were often hampered in doing so by the corporate structure, the fence-sitters who would usually not commit to taking action until there was a clear tide pushing behind them, and the nay-sayers who would pretty much be against anything new. The key, therefore, to getting employees to take action, was to let the transformers loose. Once they were actively working, the fence-sitters would see that the tide had changed and join in. The nay-sayers, of course, would still be nay-sayers, but you deal with those people separately, anyhow and try to get them into better situations.
How to get your employess off the fence? Give them a honest cause to believe in and, perhaps more importantly, engage those who are ready to act now, first.
With these sort of tenets in mind, Nayar set out to create an environment where the employees, particularly, the transformers, could catch, promote, and solve problems themselves. He turned management upside down and instead of making employees accountable to management, made management accountable to employees. Managers were there to respond to the line workers needs, not the other way around. Their shared job was to create an environment where people could easily innovate and solve their company’s problems. Of management, Nayar writes: People saw that some of the managers were little more than aggregators and brokers of information. These mangers’ entire authority lay in their control of the information. As soon as everyone had access to it, their power might come into question. And that was exactly what Nayar wanted. He recast the value of his managers not by their zones of hierarchical control, but by their span of positive influence. To help evaluate the latter, Nayar opened up the employee review process to allow any employee to comment on any manager in the company, within their functional or project unit or not.Other traditional performance review processes were changed as well. For example, instead of just rewarding support services by their time to close each submitted issue/request, Nayar’s company also added an incentive to be proactive by making the total number of requests and issues received a monitored metric as well. Someone closing 1000 issues in 10 minutes each may actually be doing a worse job than someone who only closed 100 within an average of 4 hours. It’s easy to solve long-recurring issues quickly. It’s much more useful to eliminate those common problems and leave time available to concentrate on the larger ones instead.
Nayar created a culture of trust in his company by whole-heartedly adopting a strategy of transparency and openness. Of one purpose of transparency, Nayar tells a short story: “Why do you have such large windows?”I asked my friend [who had very large windows fronting a busy street where all could see in]…. “It keeps the house clean,” he said. Transparency promotes accountability by all – both management and line worker; helps make problems, issues, and solutions, known to all; and not only keeps the house clean, but provides direct, verifiable evidence that it is so. Powerful results for a simple philosophy that is actually easier to enact than the traditional one of hiding information behind a “need to know” umbrella.
Nayar had public talks with staff members, did live video simulcasting of other important meetings, and always focused on the truth of where the company was at any given moment (for better or worse) as well as where it wanted to go. He called one aspect of this approach Mirror, Mirror which he described as … a communication exercise that involved talking with employees throughout the organization about the truth as they see it and getting them to acknowledge the reality, the elephant in the room, that everyone essentially knows about but which has never been publicly acknowledged. This exercise sounds a lot like the looking underneath the rocks aspect of Good to Great. Not only do these exercises get the employees to see and acknowledge company issues, but it often gets them known to management for the first time!
After getting the employee insights into the company’s problems and issues, Nayar engaged them in the solution process, as well. He writes: Mahatma Gandhi, Nelson Mandela, and Martin Luther King Jr. … these great leaders did not formulate strategy by retreating with their top people to a private place and then emerging to make a pronouncement to the masses. No, they walked the roads of their countries, met their people, and talked with them ceaselessly, – just like the Level 5 leader of Good to Great.
There’s a lot more to Nayar’s story than what I summarized here and I think it is also important to note that not everything Nayar tried went well. Some solutions brought unintended consequences that either had to then be corrected, or a new solution put in place instead. Other solutions, though, brought along unintended additional solutions, as well. I think a key to Nayar’s success, as well as to that of the Level 5 leaders of Good to Great, is an inclusive, honest dialog, an erring towards too much available information rather than too little, and a willingness to try and experiment with new ideas. No solution is going to solve everything, but if each one gets you further down the path to continual improvement, you’re doing very well indeed.
Scot’s best teams, both to manage and work within, were hierarchically fairly flat. Equal access to information and abilities to propose and implement solutions makes it exciting to be part of a team and working on a problem. You can create an atmosphere where people moan in the hall ways about what is wrong with the company or you can create one where people buzz in the hall way about what each of them are doing to overcome the current problems.
I recently picked up a copy of A Grand and Bold Thing by Ann Finkbeiner. It’s a book about the original Sloan Digital Sky Survey (SDSS). I actually haven’t read it yet, so I’ll probably say more about the book later, but I have had some fun flipping through the pages and reading/re-living various random passages and episodes. One thing I noticed by this quick perusal is that Finkbeiner seems to have chosen to focus her book on Jim Gunn (of course) and the Princeton / FermiLab tension that defined the project for a large part of its life. Upon reflecting on this choice, I realized there was no shortage of conflict within the SDSS and not limited to these two powerhouses. Yet, when I remember the years I spent with the SDSS, conflict is not one of the first things I think about.
No, instead I think about people’s drive and dedication to the project. I think about a group of people faced with a limited amount of time and money doing whatever it took to get their shared project done. I think about a talented group of people making each other better. And yes, I think of conflict, but a conflict born out of this shared mission, a drive to succeed, and ultimately, enough trust in each other that discordant views could be aired and the right answer would get chosen, regardless of its origin. I even remember instances where conflict was created as a mehanism to help spur progress.
So yes, there was conflict, Plenty of it. Did people get bent out of shape, angry, annoyed? Did some people cross the line and make personal attacks? Did things sometimes get out of hand? Yes, yes, yes. And certainly some of this conflict could have, should have even, been avoided, but my point here is that for this project, conflict worked very well. The Sloan Digital Sky Survey was (and still is) an unmitigated success.
That conflict was so alive and flourishing I take as a sign of a healthy organization where trust and security were high enough to allow open conflict.
I certainly don’t generally condone creating conflict to try and improve productivity (although it can have its instances). What I do condone, though, is creating an atmosphere where conflict can and does naturally arise. Only when people are being honest with each other, have passion about what they are doing, and are generally united with a common ultimate goal in mind, does healthy conflict arise. Before you try creating conflict, try creating an atmosphere of trust and security. Seek out and listen to dissenting views. Fix the system, not the person, when mistakes are made. Establish a culture of openness and trust. Help people feel secure enough in their positions to know that mistakes are not personal failings and that false harmony is not the key to a productive workforce. These things will create an atmosphere where honest conflict can arise, pushing, pushing, pushing at the boundaries of your project to do things better, faster, cheaper. If you don’t have open conflict, you probably don’t have a very high performing organization.
Another thing I think about when I think about the SDSS is the difference between projects and institutions. Projects have a limited set or resources and time to complete a task. They therefore have to be focused and directed or else their project will fail. Institutions don’t have these same constraints.With a more or less guaranteed stream of funds, they merely have to do better this year than last year. Things can wait for an institution where they can’t in a project. What’s even more interesting here, though, is that there is nothing preventing institutions from acting like projects, despite their more steady funding. I think adopting many of a project’s methods and mentalities will help propel an institution to continued excellence and to not be content with simple steady improvement.
Scot remembers one of his first days with the SDSS. Standing around the breakfast table, he commented how exciting it was to be involved in the project at the such an early stage (official survey operations having not yet started). A visiting, real longterm Sloanie simply laughed and said that this was actually closer to the end of the project than it was the beginning. A very valuable perspective was thus quickly gained.
There are some other topics I’ve been wanting to write about lately, but this one just keeps on giving…
I received an anonymous private reply to my previous post here on communications and the recent lunch meeting suggesting there are often other reasons people don’t communicate with each other besides not having an efficient infrastructure for distributing information. In these cases, we can develop the finest new tools to make sending and accessing information as easy as possible, get everyone trained on how to use them and communicate more effectively, etc., and nothing will change. We must first look in the mirror and ask ourselves why aren’t we communicating. Some possible non-communication responses to that question might be:
1) Information is power, a foundation for authority we don’t want to lose.
2) We are afraid of conflict and aim to slip things past people in hopes that no one who might disagree notices.
3) We are afraid someone will question our information and demand even more work from us, which we’d rather avoid.
I’m sure there are countless others, but I’m also convinced that a careful analysis behind these reasons for purposefully not communicating will reveal that they are, in fact, flawed. In this day and age, authority vested in the ownership of privileged information is doomed to fail. People lose authority and respect when hidden information is inevitably later revealed. If people disagree with your information/decision, better to get that disagreement out at the start than when you’re trying to get people involved to implement a plan. If a single person constantly creates discord in response to new information, then you have a management issue of that person, not a reason to stop communicating. Yes, you may get asked more questions and have to do more work, but if the result is better information, or a better decision, isn’t that work worthwhile? Furthermore, if you open your information to others, you will just as likely get support back from people with offers to help who would not have known to do so otherwise.
So, in addition to doing the experiments, and seeing what communication schemes might work better for us, I propose we need to first look seriously inward and see if there are other reasons we choose not to communicate. For if we don’t heed the latter, all the new tools and good intentions in the world will not fix the problem.
There is an interesting discussion starting from a post I made on an internal work blog. So, I thought I’d repost a slightly edited version of it here.
I attended a rather disheartening informal lunchtime meeting recently at work. One of the issues that came up involved a recent communication lapse where one group of stakeholders was not informed about a decision made by another. This kind of thing happens all the time, but it is of course instructive to evaluate what happened after the fact and see what changes can be made to help prevent future repeats.
It took me a little while to realize, but what I found so disheartening from the meeting was an apparent lack of desire to really work together to learn to communicate better. What I saw were people establishing how they were victims of someone else’s poor communications and people looking for the solution that would get the other guys to behave. In that kind of environment, it is impossible to explore solutions. That didn’t prevent many people from proposing solutions, but fault was found with all of them and the meeting ended, I thought, with general bad feelings about the apparent inaction to correcting our problems. No proposed solution solved all the identified problems, so why try any of them?
I will grant that there is no single solution to improving communications. There are tools that can be used, procedures that can be changed, attitudes and actions that can be rewarded and condoned, but no single one of these is a cure-all (yes, even archived mailing lists). Some of them will even fail, or make things worse. But what bothered me the most at this meeting was that there was no desire or commitment to try these things at all. True – each attempt might not work and nothing we can do on its own will solve all our problems, but if we try something new and learn a bit about what works and what does not, about how we communicate and expect to be communicated with, then we gain and we are more likely to eventually arrive at a package of solutions which does work. If we are too busy blaming each other, we will never be open to exploring what each of us can do to create an environment where communications and information flow freely and easily.
This image represents the result of a lot of dedicated, cross-disciplinary work in a cooperation between HIA, Gemini, and ARC. It may not look like much, but it's one of the first full three-CCD images of our new CCDs from our new controller for GMOS-N. The one dark column is a known, separate problem we are also resolving. We expect to have these CCDs available for our community to use some time in 2011.
If we had a detector controller where data were not flowing well from one channel to the other, we’d be actively debugging, swapping boards, adding ground connections, hooking up the oscilloscope to see what’s really being transmitted, etc. Why do we apply this experimental approach to our technical problems, but not our cutural ones? Why do we involve people from different disciplines to debug a detector controller, but not our communications? Learning to take shared responsibility for our communications and our communication needs is a big project, but we have ways to handle big projects. Why aren’t we applying these ways and methods to one of the most important underlying issues affecting everyone here?
(Standard disclaimer: we are making progress and our problems are a lot better ones than at many other places; it’s just that we still have a ways to go….)
Here’s an addendum I made in addressing one posted comment on the internal site:
…there are plenty of unpleasant problems that are being addressed here, but not this one. Perhaps because it is larger than the others, perhaps because it involves people and not technology, perhaps because the solutions are unknown and success not assured. It’s almost as if (which in my experience usually means it is) we are trying to outsource the solution to these problems through training, consultants, working groups, before really taking the internal look in the mirror at honestly confronting what we are doing right and wrong and owning the problem ourselves. Only after we all make an honest self-appraisal, I suspect, can we gain much benefit from these outsourced solutions. This is not something “they” need to do, but something we all need to do.
Scot realizes that no matter how good things are, there is always a biggest problem. Keeping the absolute, as well as the relative size of a problem in mind is important to maintaining perspective.
Combining my interests in German cars, international relations, and general management, I recently read the book, 1000 Days in Shanghai, by Martin Posth. The book is about Volkswagen’s initial journey to become the first international automobile manufacturing partner in China. I found several interesting themes in the book, particularly the patience and vision which the VW crew exhibited when things didn’t go as planned. When factory workers appropriated factory supplies shipped in from Germany meant for the new joint venture factory and instead used them in their own Chinese car factory, for example, Posth philosophizes (and it was probably easier doing so years later in his book than it was at the time) that when the Chinese workers saw the potential success of their new company, these kinds of behaviors would stop. Time after time, the Germans felt the Chinese violated the terms of their contract agreement while the Chinese felt the Germans weren’t living up to their word and doing what they could to improvise in a changing environment. Yet both side persevered and the VW/Audi story in China is a huge success.
Then, in a recent airplane ride, I read a brief article in the in-flight magazine that was offering advice about doing business in China. The article echoed a theme I’ve also uncovered in working with the Japanese astronomy community: the Japanese/Chinese business relation is built first on personal relationships (giri on / guanxi), then on the written agreement, whereas in the West/USA, the contract is the basis of the business relationships. The people may change, but the contract remains. Our contracts are often very detailed and precisely worded. Their contracts are broader and talk more about intentions and partnerships. We use contracts to tell us what to do when conditions change. Our Eastern partners view changing conditions as natural reasons to renegotiate the contract. Both approaches make sense, but both are fundamentally different and ripe for misunderstandings if these differences aren’t recognized up front.
So, besides knowing a bit more to expect when partnering with some of our Eastern colleagues (something increasingly common these days), this situation reminds me of another simple, obvious, yet valuable point. Any time you’re interacting with another person, whether from your own culture or one very different, it’s important to understand their environment; it’s important to state and understand each other’s expectations and assumptions. Without this understanding, there would never be a Volkswagen in China. Without this understanding, it is much harder to reach true harmony and agreement in any of your human relations.
When negotiating one international agreement, Scot remembers being frustrated while his negotiating partners complained they didn’t understand a certain passage of text. After failing at multiple attempts to figure out what wording was confusing and getting maybe just a little bit frustrated, Scot remembered that not everyone is as direct as Americans. What “we don’t understand” really meant was “we don’t like”. He could have spent all day going through the text word by word without addressing the real issue at all. With that bit understood, the problem was recognized and then fairly quickly dealt with and resolved. International negotiations are full of such fun opportunities to learn how others think.
