Its Cognitive Processes, dummy! OR Three Steps to Think like a Successful PM

What’s missing from the PMBOK?

Visualization!

FM-5 The Operations Process

FM-5 The Operations Process

Don’t want to take my hippy new ager tree hugger word for it? Well, how about the US Army then?

I’ve been on Army contracts for a while now, though never served. So I was tickled when one of my ex-Army team members said I was like an Operations (Ops) Officer.

“Ops Officer? Really?”, I said, “What do they do?”

And he said with a twinkle in his eye, ‘Read FM-5 The Operations Process, you’ll love it.’

I’m a PM geek so anything with the word ‘planning’ it is is probably gonna make me happy but hey, I am really digging FM-5, which is the Army’s Operations Manual geared towards Ops Officers and commanders.

Back to visualization….Well, not just visualization but another concept, situational understanding, is new for me, actually.

“1-18. Situational understanding is the product of applying analysis and judgment to relevant information to determine the relationships among the mission variables to facilitate decisionmaking (FM 3-0). As commanders develop their situational understanding, they see patterns emerge, dissipate, and reappear in their operational environment. These patterns help them direct their own forces’ actions with respect to other friendly forces, civilian organizations, the enemy, the terrain, and the population. While complete understanding is the ideal for planning and decisionmaking, commanders accept they will often have to act despite significant gaps in their understanding.”

So think about that from a PM perspective. PMBOK trained PMs think in terms of Process and Knowledge areas, but this gaining situational understanding is a cognitive process; a way to think. FM-5 promotes mentally pulling together the whole situation, and then with all the pieces still forming in your head…FM-5 encourages a leader to visualize.

Another excerpt from FM-5

“2-53. Commander’s visualization is the mental process of developing situational understanding, determining a desired end state, and envisioning the broad sequence of events by which the force will achieve that end state (FM 3-0). First, commanders understand the conditions that make up the current situation. From this understanding, commanders next visualize desired conditions that represent a desired end state. After envisioning a desired end state, commanders then conceptualize an operational approach of how to change current conditions to the desired future conditions.”

To reiterate – these are all cognitive processes – ie, mental, in your head, ways to think, before you’ve done anything.

  • Synthesize the facts – gain situational understanding.
  • Visualize the end state.
  • Develop a mental concept about how to operationalize the desired end state.

THENdo stuff.

I just think that’s cool. And, on a the real, I could see these three steps laced throughout the Initiation and Planning Knowledge Areas in the PMBOK, or at least, given as guidance in the PMBOK guide.  For me, adding cognitive processes could be a big win for the PMBOK.

Leadership Series Lesson 7: The Front is Always Right OR Don't be a PM Silo

Colin Powell Lesson 7

The commander in the field is always right and the rear echelon is wrong, unless proved otherwise

A software PMO is like battle command. Communications are always coming in from different units; requirements, test, schedule measurements, developers etc.

These Guys Know What's Up - Listen to THEM

These Guys Know What's Up - Listen to THEM

Just like in a war situation, a Program Manager PMO lead can be surrounded by a cadre of people who want to give her the best picture because they are concerned about their relationship to her. They all speak the same PMO vocabulary (“risk”, “float”, “CPI”, “baseline”), they all speak about things the same way (“that issue should be handled as a change request”), and they are all using the same tools (“risk register”, “IMP”, “Change Request Log”).

In their own PMO world, they don’t have to worry about learning new tools or learning new languages or understanding how somebody else works. This is especially true now that many PMs get their start from getting a PMP rather than working their way up the software development chain from say, a BA. In other words, it’s highly possible to get a group of PMO SMEs on a software project who have never worked in software development.

This means that the PMO can start to sit comfortably in its own vision of PM reality, pulling in schedule metrics and status’, not really hearing what various groups are saying and perhaps more egregious, dismissing the other group’s snapshots of reality as not true.

Here’s what happens. Inevitably, the programming lead or the requirements lead will come to the PMO with a problem. But the problem will be stated in their language using their terms. Something like:

Requirements Lead: ‘We’ve discovered that use case analysis is going to need fully elaborated data requirements in order to be complete.’

Programmer: ‘We’re having problems with our PII Stig. C&A is not happy with our use of PII’.

I’ve seen PMs draw blanks with these kinds of statements and move on to the next item in the agenda. Or worse, argue that these issues should not impact the schedule, challenging that programer or requirements lead’s vision of reality. And then, months later when the project is completely red, the PM doesn’t understand why.

As Colin Powell has probably learned the hard way, the guy or gal on the front is always right.

To prevent failure, a PM should do three things in this regard. First, know who’s on the front line of your project. Second, learn to speak their language. And third, and most importantly, hear them and believe them.

Know Who is on the Front Lines  On a software project, the front line is not your executive sponsor, it’s the users. Ultimately the users will make or break your project. You aren’t warring with them physically, rather you’re in a battle for their hearts and minds. You want them to love and use your application.

Therefore, the front line is anyone who has the responsibility for the application build in their hands. The PMO is not the front line. The front line is not senior management. The front is, at initiation, the project managers who are working with the users to determine scope. While gathering requirements, the front line is the requirements analysts who are deep diving on what the application should look be. During application build, the front line are developers. And during testing, the front line is test.

Speak Their Language Be able to speak to the front line in their language. Understand their tools and understand what they are telling you when they come to the PMO. The software PM needs to bone up on requirements methodology. Open up the BABOK and try to at least understand requirements frameworks. If you don’t understand the various elements of software architecture, sit down with the developers and let them teach you. And if they say something in a meeting you don’t understand, politely ask them for clarification. Whatever you do, don’t get stuck in the fear of looking stupid, it’s ok if you don’t understand everything, and your willingness to get clear is usually appreciated by those on the front lines.

Believe the Front Lines Don’t disregard the front line because they don’t have the same vision as truth as you and because they don’t agree with you. They’re not going to agree with you because they’re in a different reality. And that’s ok. As a PM, you want to hear an alternate vision of the truth. And you want to be able to accept it even though you may have to synthesize their version with yours to get at some middle way of truth. But whatever you do, don’t dismiss or argue it away because you don’t understand it.

Repeat after me 'EVEREYTHING'S GREAT EVERYTHING'S GREAT,  YOU ARE GETTING VERY SLEEPY"

Repeat after me 'EVERYTHING'S GREAT EVERYTHING'S GREAT, YOU ARE GETTING VERY SLEEPY"

This is about winning the war. Don’t listen to that PMO SME at headquarters whose saying ‘yeah, everything’s fine, everything’s fine’, because he doesn’t want to look bad. That person will kill your project. It happens all the time. I’ve personally seen this happen in corporate America when former Fannie Mae CEO Frank Raines’ relied on rosy pictures from his direct reports, while the ship was sinking. And even with the new show undercover boss, it’s become clear that there is a significant disconnect between top and bottom.

Don’t become a PMO silo. Know your front lines, and give the front lines the respect they deserve.

Haiti and the birth of a new Project Model

You know you’ve been off the wires when you don’t even make the Planis list. I’m just plain not on it.

APTOPIX Haiti Earthquake
Haiti’s Palais National in Ruins

So on the real, Haiti hit me like a sledgehammer. Many of my best friends are Haitian with family in Port au Prince. I have some weird connection to Haiti. Back in the day, when I was a single mom grad student with two kids under 6, someone funded a trip to Haiti for me. I was studying UN Peacekeeping at the time, and somebody anonymously informed my professor that my trip was paid for.  My second trip was again on a UN Peacekeeping tip, where I developed the program to touch base with the Haitian people about thier perceptions of the UN Mission. A sort of a stakeholder analysis mixed with customer survey tour. The idea was to figure out what worked and what didn’t work when conducting an information operation. Check that out here if you’re interested.

Anyway – I was just really stunned for a while. As you probably were too.

But, I was fortunate to find the Crisis Camp people, a group of IT professionals working with International Development professionals on using extreme programming to stand up applications that assist responders in the field. Crisis Camp meets over weekends. I would say the first two weekend were more like Joint Application Design sessions and they have now moved into full development mode. There’s still stuff to do if you want to volunteer. Some things can be accomplished from the comfort of your own home.

CrisisCampHonestly, the CrisisCamp folks are amazing. They’ve come up with databases, firmware, hardware, apps, mobile apps, collaborative sites all in a few weeks.  And this is working stuff.  I believe they represent a  new model in software development – the CAMP model. Imagine you can get all your project leads, your developers, your users together for all day development sessions week after week.    The whole team works through requirements together, then builds, then reviews, then refines, then builds again.   We PM pros should think about this a bit more.    The idea is to remove all distractions, and focus in on the thing that needs to get done.  Have the right people in the room who can make it happen.  Its sort of like agile on steroids – but different in that its not just the developers.  You do the whole thing…from strategy development, to PMO setup, and then development… in concise blocks of time.   So instead of say, talking to stakeholders over a series of months to determine a CRM startegy in a large organization,  you have a camp with all the key decision makers in the room and the goal is by the end of the day to come up with a strategy.   (You may need a few more given the reality of office politics…but just follow me on this one).  Once the strategy camp is done, they hand off to the project camp.  A project camp would  have team leads, requirements, networking, design, build, project management and determine a project strategy.  Then say the requirements team could meet with user groups in all day camps to figure out requirements.  etc. etc.  The camps aren’t like cabins in the hills, they can be in a conference room, for example.

The idea is a timebox approach.  Instead of trying to arrange around exisiting business rhythms, you create a short term business rhythm (a camp for one day).  I can’t tell you how many times I’ve heard people say ‘if we could just get all the decision makers in one room, we could figure this all out.’  Basically, that’s what the camp model is about.

camps

I know that there are plenty of caveats to this model, but I’ve heard the the Air Force does month long camps when they are developing capability documents. So rather than shop for comments throughout the organization via email, they just get all the heads in a room and hash it out.  What takes the Army 3 months to do, takes the Air Force a less than 1.

And key to the success of the camp is the collaborative online real-time information web site.  All projects need to have this.  It’s fast becoming the standard; not having a collaborative project site in this day and age is like not having email in the 90s.   Ya just gotta do it.

Professionally I’ve been swamped too. I’ve been fortunate to work on developing a model for Quality Assurance for one government agency and helping our team assist another agency develop a PMO for a large project. The lines between week day, week night and week end are all blurred at this point.

And, in this short time, I’ve learned some new techniques – more about the Integrated Master Schedule, and creating business intelligence metrics based and sourced from agency goals, traced through to process risks and controls. I’ll get more into that in my upcoming blog posts.

But the biggest growth point for me was this:

Fit no stereotypes. Don’t chase the latest management fads. The situation dictates which approach best accomplishes the team’s mission

General Colin Powell

Because on this new PMO project, I’ll be honest with you, my role is a little undefined. And that threw me for a loop because I’m all about documentation and clarity and definition. It took me a week to realize I was trying to fit a stereotype of the ‘on-site consultant providing big bad project management know it all expertise.’. Fortunately for me the bullshit meters at the client site are quite high, and I’m a big enough girl to know when people aren’t reacting to me the way I want them to, it something I’m doing, not them.

So I quickly adjusted and decided…hey, I’m going to be ok by observing the team, and following their lead. The situation is dictating the need here, not me. And supporting them, rather than directing them, is the way to go.

If you’ve read this far down, thanks for hanging in there on a long long post.  Glad to be back.

Leadership Series Lesson 6 and New Year's Eve Rant: The Hardest Thing to Do OR Leaving your Ego Behind

My first response to anything going wrong, or anybody not seeing anything my way, is anger.

I’ve come to control that impulse over time, recognize it and not let it dictate my reaction. And so many times people don’t even know.

But recently I thought to myself, how different would my work life be if I wasn’t getting bent out of shape all the time?

Yeah- I can't keep doing this.  It's just not sustainable.

Yeah- I can't keep doing this. It's just not sustainable.


Sure there are lots of reasons why I get bent out of shape, and I’m aware of those too.  I know that people are pushing a button, and that probably my reaction to the person pushing the button has little to do with them, and a lot to do with some completely anachronistic fear  they’ve triggered inside of me.

But wow, I’m going to be 41 soon and I don’t want to keep being angry.

I want my first reaction to be…..peaceful.

I have a lot of co-workers reading this blog and they’re probably shaking their heads like ‘ain’t gonna happen’.  I mean really, that Michiko fire is part and parcel of my whole PM persona.  I’m the one who expects the storm, who not only talks about the elephant in the room but sits on top of it and yells ‘yee hah’.    Yeah – I’ve gotten a lot done that way.

But I’m wondering, could I have led projects to success without the stress?

So I’ve decided in this new year, that I’m going to change my immediate response.  It’s going to take some work, and practice.  I’ll sure somebody is going to piss me off and I’ll  right then and there practice the old switcheroo.  This might be the hardest thing I’ve had to do.

Problem is, I’ve gotten too used to my fire PM persona.   Reading this Colin Powell Leadership Lesson got me thinking about it.

Never let your ego get so close to your position that when your position goes, your ego goes with it.”

General Colin Powell

My ego is wrapped like a big red bow around being the fiery PM.

So I’m changing it up in this next decade.  And I’ll tell you, I’ve already had my first test in the form of a fairly accusatory email from a co-worker.  Yeah, I got mad, I ranted, I raved.  But then I did…nothing.  I didn’t fire back an angry rebuttal.  I didn’t think about what I’d to to said co-worker on Monday.  I just consciously decided to let it go.


So we’ll see how it goes.  I’m going to sit this one out.  It may come back to damage me, but I’m practicing a new way and I want to see what happens.

Joseph Campbell’s theories of mythology inspired George Lucas to write the Star Wars Saga.  Campbell studied myths throughout the world for commonality of theme and progression, describing the connections in his book the Hero with a Thousand Faces.

One of the key things the hero always does is experience a transformation where the old self is abandoned  for a new persona.  Campbell says this kind of re-birth throughout life is necessary to maturity and growth.

And we see it our our modern myths.  Luke stops being a doubt ridden teenager and transforms into a calm, cool and collected Jedi.  Jet Li transforms from an arrogant martial art star into a mentor for others in Fearless.  Strider in Lord of the Rings becomes King Aragon.  And it goes on.

I’m not saying I’m anybody’s hero, but I am saying that I’m seeking a calmer way.  I’m interested to see if I can still be a good PM without being a fiery PM.  Wish me luck.

General Colin Powell Lesson 5: Perpetual Optimism is a Force Multiplier

Lesson 5: Perpetual optimism is a force multiplier
General Colin Powell

Lesson 5 in the Colin Powell Leadership series is something that I was fortunate enough to witness and experience at my PMI meeting last week; that is Optimism.

Its Just Better to Be Happy

It's Just Better to Be Happy

There is something really pervasive about good feeling and recognition. You know when you hear ‘good job’ and you feel slightly lighter, or when you see someone deserving get something they really need? Its the basis for the success of shows like Extreme Makeover and American Idol. When good things happen to good people, it somehow lightens up the whole group.

And leave it to my favorite branch of the Armed Services (the Army as if you didn’t know already) to come up with a term that describes that phenomena – the intangibles that gives a of group a people a boost, speeds them up, makes them happier, more effective and better.

“A force multiplier refers to a factor that dramatically increases (hence “multiplies”) the effectiveness of an item or group.” wikipedia

I wish I knew the term this week because I was definatly feeling force multiplication at the PMIWDC PM of the Year awards. I mean, a standing room only crowd at the PM Tools session listened intently to our top three candidates, really grasping what they said. It was as if the crowd was thirsty for good information on what works. And as each presentation ended, I swear it just felt really…….good in that room.

PMOTYPMI should probably do more of that, recognizing great PMs and letting them speak to all of us on what works. And indeed this was a new thing for our chapter, allowing the top three candidates for the PM of the Year award to give us their on the job lessons learned.
I won’t steal the Top Three candidate’s thunder on this blog by telling you everything they discussed, because we’ve (PMIWDC) got a webinar coming up with them and I believe a few articles from them, but it was good stuff like:

I’ve spent a lot of time describing how and why projects fail but I recently read some Authentic Happiness stuff that said what you focus on expands.  There have been times when I’ve had to force myself to focus on the positive, and be very loud and verbal about it. In team meetings and with stakeholders, I’ve acknowledged the bad while highlighting the good. It’s not an attempt to pull the wool over peoples eyes. If that was the case, I wouldn’t give the bad news.  But I’ve come to realize that dwelling on the bad does nada for me or my team, its just an energy drain.  Finding the good in any situation is an energy boost.  Like:

  • Knowing your schedule is slightly behind, but for good reason
  • Realizing a team member didn’t meet a deliverable, but understanding that team member’s motivations better, so you can give them work they will finish on time, next time
  • Failing on a project but taking those lessons learned to knock the next one out of the park

So I’m shifting a bit – I’m going to look at what works and hope that my optimism multiplies the PM forces that be.

I dunno…it just feels better! :)

Leadership Series Lesson 4: Go Deep to Go Simple

Great leaders are almost always great simplifiers, who can cut through argument, debate and doubt, to offer a solution everybody can understand.
I like what I’m seeing about simplification.  I used to work for Fannie Mae, and one of those big guys who ceremoniously came down in flames a few years ago (I won’t name names) was so incredibly obtuse!  I mean, his town halls were always full of ‘basis points’ and ‘derivatives’ and  – that’s ok for the financial whizzes in the room, but I just always came away completely confused.
So I get this.  I understand being led by someone who is not clear.  I have been on projects where the mission was completely vague.  And its not fun.  Its not….fulfilling.
So I resonated with @papercutPM’s piece on staying clear of jargon and @mkrigsman’s on Don Ward’s the Simplicity Cycle.  And of course, Colin Powell’s simple adage ‘Great Leaders are almost always great simplifiers.’
Why is simplification important?  Its important because human beings need clarity and meaning.  Make it clear and give it a good reason why and you are 95% there to motivating your team to do great things.
The paradox is that you have to go deep to go simple.  To explain things simply, you have to really understand them.
Its like say you met Dorothy on the yellow brick road.  She’s going to Oz and you’re like ‘yeah, Oz sounds cool – there’s this guy there who can make me really rich.’ So then you meet another dude and you’re like ‘ hey, lets go to Oz and get rich.’ And the guy says ‘so who is the girl?’ and you’re like ‘She’s going to ask the Wiz to help her get home and we can get rich!’  So dude number 3 is like, ‘cool..lets go.’
Then one day, a bunch of monkeys and a woman on a broom start attacking you.
Did you ever ask Dorothy her whole deal?  Why are you going to Oz?  Why are you not home?  Why can’t you take of those freeking ugly ruby slippers?????
Had you done so, your initial conversation with Dorothy would have been more like, ‘so if I hang with you, I might get attacked, but I can possibly get rich. Ok, I’m still down, but its nice to know all that.’
When dude number 3 shows up, the conversation is more like ‘ This is Dorothy, she’s in trouble. You can hang with us and possibly get rich (or get a heart or a brain or whatever) but you might get attacked.’
See – simply explained, immediately understood and full of the details you need.
Dan Ward’s brilliant Simplicity Cycle compares complexity not with simplicity but with goodness.  As you progress up the complexity slope, at some point, you stop and head back down the simplification scope which brings you closer to goodness.
And that’s where we want to be – delivering something good.    The idea is to get enough information to understand, but keep the greater goal in mind, which is to deliver goodness, something of value.
Here are a few tips to help you go deep to go simple.
Fill in the Blank
There is really only one reason why for any software development in the government. That is – The Fulfillment of The Mission.
If the agency you are working with has given you a SOW or PWS, chances are that they aren’t really describing why they need you to build them a widget.  They’ve gone past all that because they couldn’t afford to have you around when they were figuring out what they wanted.  its cheaper to figure it out and then hire someone to do the work.
So you’ve got to backpedal a bit and figure out what people are really asking for. Therefore, your first thought when given a project should be: how does this widget fulfill the mission?
how does the ______________________  fulfill the mission?
Here’s what you get in a typical SOW (boiled down).  I need a program to monitor the work in my agency.  Set up a program that does that for me.
Now you fill in the Blank: How does the program to monitor the work fulfill the mission?
Go Deep with the GAO
Start with the GAO.  The GAO stands for Government Accountability Office – they are the folks responsible for making sure that all the agencies meet their various missions. And sometimes they aren’t so nice. They can issue scathing reports on how agencies are off target, and then they present those reports to Congress who start getting upset and releasing budgets to fix the problem the GAO has identified.  Then the agency starts working on the fix and eventually hires you.  But they haven’t told you about the GAO report, they’ve just told you I need a program to monitor the work in my agency.
That’s like Dorothy telling you she’s going to Oz just to hang out.
So, go to the GAO website and search for your agency and find out if there is a smoking gun out there.   The smoking gun also exists to a certain extent at the agencies internal audit organization, usually an Inspector General (IG) office.  So search there as well.
Read the Policy/Regulation Document
The other good thing about the government is that there is a policy/regulation document that exists for every organization.  So for example, in the private sector, a business unit may pop up in response to a market need.  Chances are that the mission and reason for existence of that unit is not well documented.  Not so in the government.  Before the government can spend money on headcouunt (ie staff up a business unit) they’ve got to justify why with documentation.  Those documents show how the organization fits in the mission, and describes the mission in detail.   Org charts are more structured than private sector as well, with a clearly defined structure and clearly defined roles and responsibilities for that structure.
If you were ever a BA in a corporate environment and you are reading this, you realize just what incredible gold it is to have a document that gives you mission and organization from the start.  This is literally months of research you don’t have to do.
So lets recap, if you’ve read the GAO reports, the agencies IG reports, and the policy/regulation documents here’s where you are at the START of your program:
you understand why the organization exists – you get their mission
you understand who all the players are – you get the stakeholders
you understand why you are there – you get the intent of the project
you understand what your project is supposed to do – you get the full scope of your project
Start off with Command of the Situation
Now imagine that you walk into your first meeting with the sponsor with intelligent questions.
Instead of “What kind of system do you want?” (to which they will answer ‘ I need monitor work in my agency’ )
You’ll go in with something like this:
“I read in the GAO report that a major risk for your division was that there is a significant amount of waste because of paper manual processes.  So our role here is to create a system where you can automate some of those processes thereby gaining real time indicators of the productivity and potential risk areas in your department. Is that correct?”
Honestly, which would you rather say?
Simplify
And now, armed with good information, stop and simplify.
You should be able to answer the key question how does the ______________________  fulfill the mission?
When your team members ask about project goals,  instead of ‘this is a project to aggregate data into a business intelligence application’ you’ll say ‘we are building a system that will allow us to monitor why the agency is losing money’.
Trust me, you’ll have more motivated team members and better project sponsor support with the second answer than with the first.
Head back down the simplicity scope. Get enough information to describe your mission clearly, and know exactly what you are doing and why.  Then lead along the goodness path to project success.

Lesson 4

Great leaders are almost always great simplifiers, who can cut through argument, debate and doubt, to offer a solution everybody can understand.

General Colin Powell

I like what I’m seeing about simplification.  I used to work for Fannie Mae, and one of those big guys who ceremoniously came down in flames a few years ago (I won’t name names) was so incredibly obtuse!  I mean, his town halls were always full of ‘basis points’ and ‘derivatives’ and  – that’s ok for the financial whizzes in the room, but I just always came away completely confused.

So I get this.  I understand being led by someone who is not clear.  I have been on projects where the mission was completely vague.  And its not fun.  Its not….fulfilling.

So I resonated with @papercutPM’s piece on staying clear of jargon and @mkrigsman’s post on Dan Ward’s the Simplicity Cycle.  And of course, Colin Powell’s simple adage ‘Great Leaders are almost always great simplifiers.’

Why is simplification important?  Its important because human beings need clarity and meaning.  Make it clear and give it a good reason why and you are 95% there to motivating your team to do great things.

The paradox is that you have to go deep to go simple.  To explain things simply, you have to really understand them.

Yeah -its complicated...

Yeah -its complicated...

Its like say you met Dorothy on the yellow brick road.  She’s going to Oz and you’re like ‘yeah, Oz sounds cool – there’s this guy there who can make me really rich.’ So then you meet another dude and you’re like ‘ hey, lets go to Oz and get rich.’ And the guy says ‘so who is the girl?’ and you’re like ‘She’s going to ask the Wiz to help her get home and we can get rich!’  So dude number 3 is like, ‘cool..lets go.

Then one day, a bunch of monkeys and a woman on a broom start attacking you.

Did you ever ask Dorothy her whole deal?  Why are you going to Oz?  Why are you not home?  Why can’t you take of those freeking ugly ruby slippers?????

Had you done so, your initial conversation with Dorothy would have been more like, ‘so if I hang with you, I might get attacked, but I can possibly get rich. Ok, I’m still down, but its nice to know all that.’

When dude number 3 shows up, the conversation is more like ‘ This is Dorothy, she’s in trouble. You can hang with us and possibly get rich (or get a heart or a brain or whatever) but you might get attacked.’

See – simply explained, immediately understood and full of the details you need.

Dan Ward’s brilliant Simplicity Cycle compares complexity not with simplicity but with goodness.  As you progress up the complexity slope, at some point, you stop and head back down the simplification scope which brings you closer to goodness.

Dan Ward's Simplicity Cycle

And that’s where we want to be – delivering something good.    The idea is to get enough information to understand, but keep the greater goal in mind, which is to deliver goodness, something of value.

Here are a few tips to help you go deep to go simple.

Fill in the Blank There is really only one reason why for any software development in the government. That is – The Fulfillment of The Mission.

If the agency you are working with has given you a SOW or PWS, chances are that they aren’t really describing why they need you to build them a widget.  They’ve gone past all that because they couldn’t afford to have you around when they were figuring out what they wanted.  its cheaper to figure it out and then hire someone to do the work.

So you’ve got to backpedal a bit and figure out what people are really asking for. Therefore, your first thought when given a project should be: how does this widget fulfill the mission?

how does the ______________________  fulfill the mission?

Here’s what you get in a typical SOW (boiled down).  I need a program to monitor the work in my agency.  Set up a program that does that for me.

Now you fill in the Blank: How does the program to monitor the work fulfill the mission?

Go Deep with the GAO Start with the GAO.  The GAO stands for Government Accountability Office – they are the folks responsible for making sure that all the agencies meet their various missions. And sometimes they aren’t so nice. They can issue scathing reports on how agencies are off target, and then they present those reports to Congress who start getting upset and releasing budgets to fix the problem the GAO has identified.  Then the agency starts working on the fix and eventually hires you.  But they haven’t told you about the GAO report, they’ve just told you I need a program to monitor the work in my agency.

That’s like Dorothy telling you she’s going to Oz just to hang out.

So, go to the GAO website and search for your agency and find out if there is a smoking gun out there.   The smoking gun also exists to a certain extent at the agencies internal audit organization, usually an Inspector General (IG) office.  So search there as well.

Read the Policy/Regulation Document The other good thing about the government is that there is a policy/regulation document that exists for every organization.  So for example, in the private sector, a business unit may pop up in response to a market need.  Chances are that the mission and reason for existence of that unit is not well documented.  Not so in the government.  Before the government can spend money on headcouunt (ie staff up a business unit) they’ve got to justify why with documentation.  Those documents show how the organization fits in the mission, and describes the mission in detail.   Org charts are more structured than private sector as well, with a clearly defined structure and clearly defined roles and responsibilities for that structure.

If you were ever a BA in a corporate environment and you are reading this, you realize just what incredible gold it is to have a document that gives you mission and organization from the start.  This is literally months of research you don’t have to do.

So lets recap, if you’ve read the GAO reports, the agencies IG reports, and the policy/regulation documents here’s where you are at the START of your program:

  • you understand why the organization exists - you get their mission
  • you understand who all the players are – you get the stakeholders
  • you understand why you are there – you get the intent of the project
  • you understand what your project is supposed to do – you get the full scope of your project

Start off with Command of the Situation Now imagine that you walk into your first meeting with the sponsor with intelligent questions.

Instead of “What kind of system do you want?” (to which they will answer ‘ I need to monitor work in my agency’ )

You’ll go in with something like this:

“I read in the GAO report that a major risk for your division was that there is a significant amount of waste because of paper manual processes.  So our role here is to create a system where you can automate some of those processes thereby gaining real time indicators of the productivity and potential risk areas in your department. Is that correct?”

Honestly, which would you rather say?

Simplify And now, armed with good information, stop and simplify.

You should be able to answer the key question how does the ______________________  fulfill the mission?

When your team members ask about project goals,  instead of ‘this is a project to aggregate data into a business intelligence application’ you’ll say ‘we are building a system that will allow us to monitor why the agency is losing money’.

Trust me, you’ll have more motivated team members and better project sponsor support with the second answer than with the first.

Head back down the simplicity scope. Get enough information to describe your mission clearly, and know exactly what you are doing and why.  Then lead along the goodness path to project success.

Leadership Series: Oh, I get it – it's all about Leadership OR that PMP is not Enough

Leadership is the art of accomplishing more than the science of management says is possible.

Colin Powell

I  just simply adore Twitter.  I have met the most amazing people and am now actively involved in the creative synergy and challenging of ideas.

Fascinating!  A whole new way to look at things in 140 characters.

Fascinating! A whole new way to look at things in 140 characters.

Here’s the thing – @BackFromRed and I had a chit chat.  We’re both pretty good at resurrecting projects from the brink of destruction and so sharing notes we both lamented the fact that while process is followed to the “T”, projects still fail.

The sad thing is that I don’t think certification is the key.  I’m a certified PMP, an active PMI volunteer and I adore my chapter and the people therein.  But we have to start looking at certification as the jump off point.  Certification gives you the method, the thinking process, the tools you need to know what to do next.  It’s General Powell’s ‘science of management’.   But certification doesn’t teach you how to lead, which, if we believe the good General, will enable us to accomplish more than any scientific method suggests.

To PMI’s credit I believe the organization is embracing the need to develop Project Management leadership based on things like conflict resolution, ability to communicate, ability to inspire.  The December 2009 PM Journal has an article titled “Developing Soft Skills to Manage User Expectations in IT Projects”.  ‘Interpersonal Skills’ was a major track on the Global Congress this year.   And most importantly, PMBOK version 4  includes a nod towards Organizational Development  (Section 2.4.1 – Organizational Cultures and Styles),  and a whole Appendix (Appendix G) dedicated to Interpersonal Skills.  I have mad props for the PMBOK because it represents the basis, the elaboration of formally verbal non-documented methods.  But with any endeavor, it’s easier to describe tools and processes. But it’s harder to describe the best way to use tools and processes.  Harder still to describe the ephermal concept of ‘being great at something’.

This topic is hot in the blogsphere.   This CNN article recommended by @RosaSay on Twitter  describes”five skills that separate the blue-sky innovators from the rest — skills they labeled associating, questioning, observing, experimenting and discovering.”  More PM Specific, @PMStudent recommend a study by Terry Maighnath deep diving into the Behavioral Traits of Successful Project Managers.   The message is certification, and even years of experience are not enough.  Reference @ambidexterman‘s post on a Harvard Biz article about PMs who actually stop learning from experience.  Disturbing.  As @Meridiths says in her article The 10 Key Capabilities of Next-Generation Project Managers “Project Managers need enhanced leadership skills”.

My thing is, the discussion treats project management and leadership as two tangential things; specifically leadership as a trait that enhances Project Management.  But I think that Project Management is the first step in the discipline called ‘Leadership’.  It’s the ‘thing’  we are aiming for in Project Management.

So for example, the aim of dance instruction is the creative expression through dance, not just technique.

The aim of car mechanic instruction is the ability to diagnose and repair cars, not just knowledge.

The aim of surgeon instruction is the ability to save lives, not just understanding how to save lives.

The aim of project management instruction is not Project Management, it’s the ability to lead.

The Art Of Dance

This is not JUST technique, you don't get here by JUST going to dance class.

Leadership.  This is what I believe is the reason for Project Management.  And that’s why certification is only a first step.

So using the surgeon analogy:

A surgeon’s goal: save lives quickly. For that privilege, one completes a lengthy training program, passes a difficult test and then emerges and is deemed…a novice.  The whole medical profession disrespects you, is mean to you, assumes you know nothing –and this is after the training and test.  That’s because the medical profession understands that without the hand-on experience and mentoring, you are not really a surgeon yet.

Imagine if we took this approach to the Project Management profession. What if getting a PMP was just the Step 1.  Step 2 would be a mentoring period where we would learn the soft skills described in PMBOK 4 Appendix G; team building, motivation, leadership, communication, influencing, decision making, political and cultural awareness and negotiation.  And then get tested on that!  I would venture to say that we would see a huge reduction in project failure.  The path to accomplish a program like this is rather daunting; how would you pay for this, how would you test for it, how would you make it certifiable?  All tough questions.

However, at some point, the cost benefit analysis will become evident.  It will be costlier for PMI to take the reputation hit of turning out PMPs who are behind project failures, than it will be to train those PMPs on the people skills that prevent project failures in the first place.

It’s like @BackFromRed says, without leadership, the processes will fail.