Developers get a bad rap from us IT PMs.
We IT PMs have a sort of prevailing wisdom about dealing with the ‘devs’. We even talk about it in our job interviews as a known issue; this idea that Devs are cantankerous arrogant curmudgeons, and we need to have certain skills as PMs to navigate through Dev incurred roadblocks to timelines.
Well, I’ve worked with and been friends with Devs for a long time and I think it’s time we think a bit differently about them. From what I’ve seen, Devs have always been good to me (made deadlines, stuck to process, built incredible things) when I’ve thought of them, and given them high regard.
I think any PM will see an improvement in Dev-Pm relations if you remember and adapt to the following:
Appreciate The Knowledge
Developers are like skilled artisans; people who shape, and mold an idea into something concrete, movable, usable. We respect someone who, for example, builds a beautiful table, because we understand that the ability to merge art and function is unique and rare. Perhaps because there is so much work, and so many developers, we tend to down play the work they actually do.
With an artisan point of view, we should approach developers with an appreciation for their knowledge. This attitude manifests itself when we interpret questions around requirements not as stone walling, but instead, a desire to build the best thing possible.
Artisans tend to develop a sense of pride in their creation. We should recognize that when we shift gears too suddenly in requirements, that thing in which pride was taken, has to be tabled. There is some kind of human cost to this, a disappointment. Multiple disappointments can lead to bitterness. As PMs we should recognize this sensitivity. Our role in controlling the process and QAing and ensuring good requirements is key to minimizing this phenomena.
Trust the Delivery
I approach that edge of the full elaboration of requirements and the beginning of the magical transformation into something functional carefully. As a team, we want to explain the design, but relax and step back slightly to allow the technical ability to form idea into function to show itself and flourish.
I think a lot of PMs have a hard time letting go at this point. We often want to know the exact details of how something will be built. So we have to employ trust and allow the development team to prove that they can deliver. Paradoxically employing trust, even if things arrive a little late, serves to open up the channels of communication about the details.
I learned this directly from a dev manager when he suggested that instead of questioning why something was done by a certain date, I instead inquire about the complexity of an item. The implication of ‘is this more complex than originally thought’ is that the developer is doing their job. The implication of ‘why isn’t this done’ is that the developer is not doing their job. Subtly of approach respects the individual and lends towards a better delivery.
Give em a say in the Process
Contrary to popular belief, I think most developers actually like process. I’ve worked with dev teams who’ve initially resisted process become dev teams who champion process. The win for the developer is when process produces good requirements, be they requirements documents, or super clear user stories with well thought out acceptance criteria. The other win for process is when the process keeps WIP at some kind of sanity level to allows the developer to do the kind of work they take pride in, and the team to trust the delivery. Monitoring both – clear requirements and scope sanity – will be an immediate win to reducing barriers to process.
Especially when it comes to code migration process, we can really engage developers. Let them create the process while providing guidance that the process should be simple, clear, clearly elaborate roles and serves to ensure traceability. PMs can help by then documenting what the developers agreed to, helping to shore up any holes in the process, and then acting as an oversight on that process. The key is it’s their process, not something that was dropped on top of them.
Course, those three things, appreciation, trust and communication are the basis of all good human interaction. PMs, let’s do what we can to make sure that when it comes to developers, we employ these tools to become partners, not antagonists.
I used to think that it was just me. Like I would go into new project environment and feel like ‘ugh’, the human emotional soup was all gross and thick. People were so mean on one project that when I tried to bring two representatives of opposing groups together, as soon as the IT rep walked in the room, the business PM yelled ‘WHAT IS HE DOING HERE!?’.
Is it possible to really have a successful project when there’s nothing but human muck flying around?
I never thought so. And now a new study suggests that yes indeed, there is such thing as a ‘feel’ to a project…they call it the Project Spirit. And there’s some data to suggest that a good Project Spirit will result in Project Success.
This seems a little common sense….HOWEVER. There are still people that believe that a) people have to do their jobs, and b) they have to bone up and have tough skins and not be so sensitive and c) none of this emotion stuff affects how the job gets done.
WRONG – the emotion stuff absolutely does affect the project.. absolutely does.
Here’s more on that…
Project Spirit and Project Success
I like this idea of Project Spirit.
Seems kind of hokey at first, but according the February 2013 PM Journal article “Managing the Intangible Aspects of a Project: The Affect of Vision, Artifacts and Leader Values on Project Spirit and Success in Technology-Driven Projects” by Aranson, Shehar, and Patanakul, Project Spirit is actually a thing that can be measured.
Basically Project Spirit is:
- Behavioral Norms
…0f the project participants.
The article suggests that certain activities, which they call Leader Building Activities, affect the Project Spirit.
These activities are defined as:
- Vision, and the ability of the leader to articulate a vision that people want to follow
- Values, and the ability of the leader to instill their positive values into the project team
- Artifacts, the rituals and symbols of the project
The causal relationship is that the Vision, Values and Artifacts (Leader Building Activities) affect the Emotions, Attitudes, Behavioral Norms (Project Spirit). FInally Project Spirit affects what the authors describe as ‘Contextual Performance Behavior.’
“Contextual performance behavior involves voluntarily assisting coworkers in various ways, taking on additional assignments, keeping a positive attitude and tolerating inconveniences at work. Contextual performance behavior generally has two common themes: It is representative of the employee’s extra efforts that contribute to productivity, and it is not directly enforceable, meaning its is not technically required as part of one’s job“
And it’s this contextual performance behavior that can affect project success.
The authors set out to prove that “Project Spirit positively affects contextual performance behavior” by analyzing NASA Mars projects.
Mars Pathfinder, a succesful project, was one where Project Spirit was managed through setting a clear vision, management that set an example through their own tone and behavior (values), short effective meetings, team happy hours, colocation (artifacts). The vision, values and artifacts resulted in a team that had a certain sense of excitement (emotions), a commitment to the people on the project (attitudes), and high spirited group of people who valued honesty (behavioral norms).
Mars Climate Orbiter, a failed project, was one where Project Spirit was not managed. The vision was driven by cost savings,
management “lacked a balance between confidence and arrogance”(values), a sense of the need to build a “protective shield to outside option..or expert involvement”, a leadership that lacked a ‘collegial relationship with team members’, and a team that was not co-located (artifacts). Emotionally the team was very invested in success (emotions), resulting in an attitude to devote “lives, weekends, and time” (attitudes), and a “diminished culture of inclusion” (behavioral norms). This resulted in an over taxed workforce who weren’t open to outside input that could guide the project (behavior outcomes).
The project that set a positive emotional tone through clear vision, people-affirming values, project rituals and symbols resulted in a place where people felt excited to do their jobs, and went above and beyond what they were supposed to do, was a clear success.
So yea…it’s not just you! There is a feel to that project, and as a PM there are things you can to do start to change that context and bring in a positive Project Spirit through setting clear vision, instilling positive values and setting up artifacts that build a sense of team. Read the article for more ideas.
Side note: I’ve been on a Battlestar Galactica jaunt and if you want some good examples of how to do this, watch President Laura Roslin and Admiral Adama. They do this really really well. Adama is always instilling values, Roslin is always insting on rituals to build morale, and together they build a vision to get to Earth. Somehow they build a positive Project Spirit in a really bad situation.
Today I’m inspired by Andrea Brockmeier and Elizabeth’s Larson’s article in Project Times concerning 2013 Trends in Project Management.
“Project professionals need to provide advice, not pushback. Several years ago organizations told us that they wanted PMs and BAs to be able to push back when their stakeholders asked for new requirements. Some of these organizations are now seeing that pushing back is one way to avoid being an order-taker, but it is less effective than providing well-analyzed advice. Our prediction is that more organizations will want PMs and BAs to be trusted advisers (sometimes called trusted partners).” from http://www.projecttimes.com/elizabeth-larson/2013-trends-in-business-analysis-and-project-management.html
I would just like to add on to this idea.
Over the past couple of years, I’ve run into Project Managers who are expert Push-Backers. I think a lot of them don’t really know what advice giving really looks and feels like. I think that they are so used to being ‘IT’ that they adopt push back as part of the culture. I have at times been a push-backer but fortunately I’ve had really painful experiences that have forced me to be more of an adviser. So having sat on both sides of the fence I decided to write up a few things that indicate to me what an adviser looks/sounds like vis what a push-backer looks/sounds like.
Here we go:
Investment in the Solution
The IT Adviser PM:
You’re not really that invested in the solutions proposed. You care, because you want the best thing for the project, but if the wrong decision is made, you feel that you’ve given it your best shot and that’s it. You recognize that giving all the info was your role, the decision was not your role.
The IT Push Backer PM:
You are absolutely invested in the solution you’ve presented. You feel emotionally distraught if things don’t go the way think they should. You think any decision that is different from the one you’ve already made in your head is wrong.
The IT Adviser PM:
When you listen to solutions or directions other than your own, you really listen. You’re open, you consider, and you build on what you’ve heard.
The IT Push Backer PM:
When other people give their ideas, you look for ways that those solutions won’t work. You are vocal about how those solutions won’t work.
Respecting Others Knowledge
The IT Adviser PM:
You think that business people, even though they aren’t as knowledgeable about systems as you, should be given respect for what they know about their business domain. There are things you recognize you don’t know, and you are open to learning.
The IT Push Backer PM:
You think that business users should pretty much stay out of systems. You know the system, you know how it works, and they don’t need to know too much about how things work. Business knowledge is important, but only to the extent that it results in good requirements/user stories.
The IT Adviser PM:
You think about what could go wrong because you want to make sure that the solution succeeds. You bring it up and talk proactively about risks, and you give business users a way to discuss risk without it being personal.
The IT Push Backer PM:
You think about the solution as an IT solution. Anything that happens outside of IT must be resolved by business users. One major risk that you see is the business not having their act together and wasting your people’s time. You actively guard against this risk.
So which one are you? Chances are you’re a little bit of both. Chances are you have to shift between a continuum that has adviser on one side and push backer on the other depending on who you’re dealing with. But if we are to look at the trends, as suggested by Brockmeier and Larson, it can’t hurt to take a personal time out and think about how you can develop some refined adviser chops for the future.
December 15, 2012 Making Theory Usable: Tips to Go Beyond the Lesson Learned and Really Change Behavior
- Sometimes we reflect
- Sometimes we use metaphors
- Sometimes we have constructive conversations
- Sometimes we assess our impact
There is new research that suggests that if we are able to combine these modes of communication into one game like activity that’s fun and intuitive, we can help our teams communicate more effectively. Dr. Arthur Shelley is developing these ideas in his Reflective Performance Cycle (RPC) and wrote about it in the most recent PM Journal (December 2012).
Metaphor is defined as: A thing regarded as representative or symbolic of something else, esp. something abstract. Using metaphor helps to enable people to talk about behaviors in a way that separates the person from the problem.
Reflection is something we already do in the lesson learned, where we think back and analyze what happened in the past.
Constructive conversation is when you use the conversation to achieve an outcome. In other words constructive conversation is a discussion of a subject upon which, at the end of the conversation there is a decision or an action in relationship to that subject.
Impact is something we touch on in the lesson learned sometimes, but this article suggests that we role play and pre-evaluate the potential impact of behavior, before we engage in that behavior.
This makes me think about how I set up meetings, aka what-I’ve-learned-to-do-from-leading-crash-and-burn-meetings in the past. When I set up meetings, I always describe the behavior and the method of the meeting. So for example, I might say:
This meeting is to discuss the most recent production push. Please think ahead about those things that worked and those things that didn’t.
We are going to:
1. Discuss what went well
2. Discuss what didn’t go well
3. Brainstorm ideas about how to shore up areas that didn’t go well
4. Decide which changes we can make right away
I think that most agile teams build this type of reflection in with a standard sprint retrospective. But what I’m talking about here is setting up the desired behavior that you want from the team, in advance. By sending a message like this before the meeting you are:
- Using a metaphor, brainstorm, to describing the way the team will interact.
- Describing the desired behavior from the team. We will think, we will describe, we will decide.
- Asking for reflection ahead of time: please think ahead about these things.
- Indicating that the conversation will have an outcome; therefore it will be constructive: decide which changes we can make right away.
This type of message engages the human brain in setting the stage. I’ve found this setup to be really useful in getting the desired outcome that I’d like.
But here’s the meat of the matter
The article provides even more delicious ways to engage your team by combining behavior, reflection, constructive conversations, and impact assessment.
One activity that I believe shows promise can be run with a team where “participants can pre-select which behaviors are the the most appropriate for achieving the desired outcomes of each
conversation, depending on the situation” (Shelley, PM Journal, December 2012, Page 89).
I could see an IT team using this to help smooth communications with their business stakeholders. This activity would be done without the business stakeholders.
In the activity, a deck of cards is used. Each card has a type of animal. Because of cultural conditioning, we all have ideas about animals and what they represent. The lion for example usually represents decisiveness and bravery. While a snake usually represents sneakiness.
Shelley describes this activity:
“The nine members of the group were asked to (Individually) use the cards to profile at least one of their stakeholders with a view to understanding them better.
They were instructed to consider how they should behave in order to secure their desired outcomes from the next interaction with the stakeholder.
Before engaging with the stakeholder, participants were encouraged to role play the planned interaction or at least discuss it with peers.
[Other] participants were asked to record and challenge their thoughts regarding the interaction with the stakeholder in a reflective impact diary template.” (Shelley, PM Journal, December 2012, Page 90).
Breaking it down, the activity goes like this:
Using a metaphor for behavior (the cards) describe the behavior of a stakeholder.
ex. “The project sponsor is a Pirana. Everytime I go to talk to them, its like a feeding frenzy, they jump all over me with everything that could go wrong.”
Think about the next interaction with that stakeholder and consider how the team member should adjust their behavior in order to get the desired outcome.
ex. “I could not jump in the proverbial water! Perhaps if I prep myself by considering the good and the bad that could happen ahead of time, and then approach them with a more complete analysis, I’ll pre-empt the strike.”
Role play the new behavior.
One team member plays the stakeholder. The team member would practice the new behavior while other team members record the interaction.
Reflect on the role play and assess the impact of the change in behavior.
The observing team members share their reflection of the interaction, and adjustments are made.
Check out Dr. Shelley’s slideshare presentation to learn more:
Just a quick note to say…
I LOVE THIS!!!
click to see it in its full glory
Created by Simple Square. Portfolio website design specialists.
I need the template!
A while back I wrote about the Project Management Institute’s 2011 Journal Paper of the Year by Manfred Saynisch.
“Here’s the deal – what Saynisch et. al. are proposing is a fundamental shift if the way we think about project management. We are moving from Project Management First Order to Project Management Second Order. And it’s all about the shifting collective beliefs…. Project Management theories and processes should start incorporating these ideas:
- INSTABILITY IS TO BE EXPECTED
- CRISIS IS AN EXPECTED OUTCOME
- RAPID EVOLUTIONARY JUMPS PROVIDE A CHANCE TO EVOLVE TO A NEW LEVEL, EMPLOYING THE PRINCIPLE OF CHANCE”
As PMs we do expect a bit of progressive momentum on our projects, regardless of the method we choose. If we are in an iterative project, we expect progression to the plan. On agile projects we expect a certain rhythm; standups by day, planning, showcases and retros every few weeks.
But what happens if we accept Saynisch’s idea that we should accept that instability, crisis and rapid evolutionary jumps will occur, just when we least expect them?
Here’s the issue: we have the techniques and tools to plan for crisis (though I would argue most places don’t use them), but we don’t really talk about what our approach will be as Project Managers when control is seemingly lost. How do we, as people, make it through? How do we prepare our thinking for crisis? What expectations do we have about what we will or will not do during those times?
A Short Minor Crisis Story
I have one story, a positive one, about managing through minor crisis. As a program manager at a small company, I had been working hard to raise the level of project management maturity. With over 30 projects, we hadn’t connected projects to strategic programmatic goals and we had not prioritized the projects. People were going slightly nuts.
I (obviously) wanted to get a handle on this. Over time, I developed the relationships to have the senior leadership trust me enough to begin to work on these issues. After a number of months I was able to get all the execs in a room for a portfolio planning exercise. And the goal was simply, place the projects into strategically aligned portfolios.
Within minutes it became apparent that my plan was going awry. The cool card sorting thing I envisioned was confusing people. And the discussions were moving away from the topics I wanted. And I thought ‘ dammit, I’m about to lose a golden opportunity’. The execs started questioning why there were there. Schmuckers!
But..I had done my research. And I knew where the problems lie and I started to honestly communicate. I admitted immediately that the method I had envisioned to solve the problems had gone a little nutso, but reiterated that we could still solve the problems we faced. Then there was discussion amongst them, and I sat back and let it unfold. Which was hard. I didn’t know where it was going. But the problems we faced had been laid out before us, and we all knew we had to solve them. And then, like instant magic, they decided, en masse, that instead of portfolio planning, they were going to prioritize projects.
And I was like ‘Booyah!!’. That was better than I could even have hoped. My original plan got thrown out the window (thank God), and during the turbulence between the old plan and the new, the things that helped me keep up forward momentum were:
- the relationships of trust I had with the team (they’re thinking “Michiko’s not an idiot, so I think we must be here for some good reason”),
- the knowledge I had (I’m saying “Hey folks, we have some serious issues to solve here; here’s example 1, and here’s example 2”), and
- it was ok to abandon the method to move forward (“well, looks like the card sorting exercise is a bust, but what can we do to solve our problem”).
And the outcome was fabulous.
It could have gone something like this: I keep trying insanely to stick to a method that obviously was not working, I shut down. I say something like ‘ok, we’ll pick up at some other time.’ They then lose faith in me, I lose some cred. We stop moving forward.
Preparing our Human Project Manager Selves
Saynisch’s model says that we should expect crisis, and out of crisis we will experience evolutionary jumps. I think the implication of that model is that we need to plan and prepare our personal response to crisis.
In other words, what are we thinking when the you-know-what hits the fan? How do we manage ourselves well, so that we have the right expectations and subsequently help to manage others well? What do we hold onto and what do we let go to make it through?
What I’m suggesting is that shifting our paradigm to expect crisis also involves shifting our approach to project management during these times of crisis. I thought I would share with you some of my own learning from crisis periods, and how I’ve adjusted my approach to fit those crazy times.
So here are three things that I think happen during crisis and three changes in thinking that I think may help you prepare and manage through crisis.
In crisis, trust relationships trump authority
Crisis represents the breakdown in normalcy. And during crisis the normal reporting relationships and hierarchies will not be as important as who people actually trust. In crisis, people will follow who they trust.
Implication: If you want to lead through crisis, develop relationships of trust.
Build your relationships. Work to appreciate people and what they do. If you have beef with people, try to work it out. Make sure you know the names of everyone on the project and understand what they do and how. Take time to talk to people about life in general. Revisit your own methods, see where you can adjust if you have an area that needs work. Read a self-improvement book. Read books about team building.
In crisis, knowledge trumps authority
Similarly, people will most likely follow those who know how to get out the crisis, not the stated authority figure.
Implication: If you want to lead through crisis, keep learning; fill yourself up with knowledge. The more you know, the more you’ll be able to quickly connect the dots to develop a plan for getting out of the crisis.
During times of normalcy, become knowledgeable about everything related to your project; how the enterprise works, what systems do what, how communications occur. Most importantly know the intimate details of your project. Read the requirements, read the test scripts, understand the business benefits and know why the enterprise needs to achieve them.
In crisis, forward momentum is more important than method
During crisis, Its more important that group feels that they are somehow making progress rather than that they are following the norms and rules of methodology.
Implication: Be willing to abandon the method, in favor of forward momentum. And then communicate like crazy, all the time. Because method is really about communication. And you’ll have to pick up that slack.
Be hard on yourself about communication. Make sure everyone knows as much as they can. Walk around. Tell people. Email. Post it on Yammer. Use every form of communication you can to tell people what’s going on.
Avoiding the Shutdown
Here’s what some people do in chaos: Shut down. Stop communicating.
Why? Because they don’t have the knowledge, they don’t have the relationships and they realize that without both they won’t be able to do the communication necessary to keep forward momentum going. And they know that as soon as they start speaking people will realize it. And in extremely chaotic situations, people will stop following them and follow the person who does have the relationships and the knowledge.
Let’s prep ourselves to avoid the shutdown.
So these are just a few ideas to start the shift in thinking. What do you think? What crisis experiences have you had to manage through and what did you learn?
Today I’m inspired by Richard Branson, founder of Virgin Airways.
In providing his best tips for starting a successful business his number 2 is, “Keep it Simple”. He says
“You have to do something radically different to stand out in business. But nobody ever said different has to be complex. There are thousands of simple business solutions to problems out there, just waiting to be solved by the next big thing in business. Maintain a focus upon innovation, but don’t try to reinvent the wheel. A simple change for the better is far more effective than five complicated changes for the worse.”
A simple change for the better is far more effective than five complicated changes for the worse. – Richard Branson
Have you ever been on a project where things changed massively all at once? Sometimes the change is necessary but there’s no denying it wrecks havoc on relationships. I’ve been that PM in the past, the one who wanted it all to go by the book; the perfect project plan, absolutely correct adherence to the SDLC (whichever method we chose) .. and I would push really hard, early on. And wind up being the one who bought in ‘five complicated changes’ that inevitably made things worse.
And it wasn’t methodologically worse; it was relationship worse. The changes were so sudden, they pushed people immediately into taking sides. People never got to really know me as a person, I just became that PM, the one pushing everyone’s buttons the wrong way. I hadn’t learned this truism that really…
…One simple change for the better would have been far better than the perfect methodology (and the 5 changes that came with it).
Now, I’m a little bit more relaxed. I see things every day that I wish I could change, or hear things that make the SDLC-lover inside me want to run for the hills. But…its one thing at a time. Crawl.Walk.Run. I’m focusing my energy first, on appreciating what people are doing, rather than trying to analyze them against a methodology checklist. Second, I’m looking for that simple change that will make things better for everyone.
Here’s one idea from the most recent PM Network A PMO in Kentucky doesn’t force low probability risks into the risk management process. “ ‘We make note of it and discuss it informally.’ Says Janice Weaver, associate vice president of the EPMO at Norton Healthcare. ‘But we don’t spend hours on tasks that don’t add value to our process.’ “
What’s one small thing could you do on your project that would make things better?
Here’s two guys who’ve mastered simple play Simple Gifts..wouldn’t it be awesome to feel like this at work!