Teaming on DoD projects … Tackling Fuel

If you are a team leader working on a DoD project there are challenges that you face which are unique simply because you are working for the DoD.  There are some very basic concepts to understand in order to create or facilitate success.

1) Do what you can with what you have.

You have to play the cards as dealt.  You are in a situation where turkeys are all around you!  Expecting things to get better is unreasonable and won’t help you.   Working to get everyone to see things the way you do, MAY not work either.   People that you work with or around may not give a crap about what you are doing and there may be no adverse impact to them if they ignore you.   What I have found that seems to work somewhat is to be clear about what you are working on and be clear as to what you expect your team is expected to accomplish.   I normally come up with a Plan of action with milestones but I add mission, vision, scope, objectives and a mapping of what we are doing to why we are doing it via policy, standards and guidance.

Historically speaking about 70 – 80% of the team is ok with this and on board to do the work.  If you think that is a low number, chances are you a commercially oriented person or a military commander.  What I am talking is somewhere in between those two guys/gals.   The difference is that even though YOU are supposed to be in charge, YOU have no real ability to enforce a consequence.   In that situation, some people ignore you.  When that is the case, I don’t ignore them but I talk to them about the situation and try to come up with an understanding. Sometimes it works, sometimes they wind up playing solitaire or reading the news paper all day, everyday.

2) Write and remember.

I normally keep a high level log of events, like a journal without all the feelings!  I do this for a few reasons, firstly because I have no idea what I did last week without it.  Think back to September 29th, 2011, you were supposed to have the project implemented already.   You needed to get your IA accreditation, your system needed updates, you were supposed to be supporting 2000 users and you had 15 client deliverables.  Oh by the way it was a Thursday.   How would you know what happened that day or any other?  Make and keep those notes.   They are important for many reasons.  You need them for Project memory, and for turnover if you need to do that.  You need those notes for reporting on deliverables or reasons why you failed to deliver.  If you are looking to win other contracts, you can use those notes to discuss and document your quals.   These notes are critical to your project because chances are no matter what you are working on you will restart at some point in some fashion and you should be able to get a head start with what you have already.   For my notes I use the personal brain now called “thebrain”, mind maps, discussion threads (in my case on Forge.Mil).  I do use documents as well but I normally map them by linkages in a system so that everyone can see what I have written.

3) Too much information is bad.

Just kidding, I think it is up to you to know how much information to use.  Every client is different and it really depends on your trust relationship.   If you are a civilian project leader meaning a GS-type,  this is still relevant.  Sometimes too much information is presented at one time and leadership is overwhelmed by the sheer amount of data.   In that case you just go with something like the 10-20-30 rule.   10 slides max, 20 minutes at the most and 30 point font.   Even that can be too much, General Mattis who now is in charge of CENCOM didn’t seem to like power points, he just wanted the facts on one sheet of paper and as I remember (tell me if I am wrong) you had to keep it to 10 things.   Other leaders I have personally worked for liked marathon all day planning and discussion sessions.  I have seen 8-10 hours of work breakdown and discussion.

4)If you are angry chances are you care.

If you are angry or frustrated, there is a good chance you care and/or you are taking yourself or this project too seriously.   Here is a note about me,  I get frustrated because I care .  The problem is that caring is great but it doesn’t get results.   A senior leader and friend once told me “Howie, worrying is like sitting in a rocking chair, you can do it often and get nowhere.”  I am sure that he took that from somewhere but that is what and how he said it to me.   Fact is, he was and is right.  At the time when he told me that I was working on a multimillion dollar project that had “must have” deliverables and kept me up nights and weekends.   Not long after I left the project all of the work was put on a shelf .  It was like watching Indiana Jones when they boxed the Arc.    I was like “whhaaaa”  That being said, of course we should care about our work but we should not allow it to bleed us.

5)Any project or program method is OK as long as at the end of the day your client, customer, boss etc gets what they need.

If you like Agile project management or you are a PMP it really doesn’t matter.  How you choose to run your project is really up to you and your team.   By the way, if you think it isn’t up to your team see 1) and take the number from 70-80% to umm 5-10% because the only one that will be working is you if you don’t get your team on board.   Once you figure out what you are doing and what process you are going to use, go back to the person you are working for and make sure you align what you are doing with what they need.   What this means is that you are going to do things the way you know how and meet their needs.  A lot of people would say figure out what the client needs first but I am not talking about requirements, I am talking about how you are going to work your project.  Those are two different things.    “Howie, I want you to build me a race car… make sure it is fast and has lots of lights!”  OK… yes I can do that..  Of course there are lots of questions I would ask to get the car specifications but unless my client hands me a “how to” guide, I need to be trusted to execute the process with my team the way WE feel we should.  The METHOD is up to the project manager or team leader.    This is where trust comes into play, and you need trust.   So.. SCRUM if you want!

Really, what I am saying here is that as a team leader you aren’t alone and there are people out here that understand your frustration (pain).  Working together we can help each other by sharing ideas and information.  Ultimately, everything boils down to communicate, collaborate, cooperate!

Happy Sunday