Project Managment: Reducing Pomp and Circumstance

Before I get started with this post, I want to spend a little time discussing my last post focused on Developers.  One response came back and had several great points that I wanted to echo back to the full audience. 

In summary, JR made the point that Developers are generally a smart crowd and provide passive resistance when they sense the PM is playing games with the team.  To the point made in the response, the PM role and most other roles in the entire lifecycle support the applications being created by the development team and are there to help increase the efficiency of the team.  Great Project Managers will put the needs of the entire team before themselves and will work to increase the efficiency of the individuals - software engineers, quality assurance engineers, infrastructure engineers, UAT Teams, marketing, etc.  They will focus on removing roadblocks, opening communication and staying ahead of the team.

Now, on to the topic at hand.  One of the things that I've seen frustrate Senior Leadership Teams is when Project Managers and Project Teams begin to use the process as an excuse for not delivering!  The process is in place to ensure conformity to a basic set of processes and procedures.  That doesn't mean that every project needs every step of the process, nor does it mean that every project needs every artifact defined within the process.

I challenge each of you to look at the projects that are running through your organizations and ask the following questions:

1. How complex is the effort defined within the scope of the project?
• If this is a minor change to a system already in place, and there's agreement on the scope and requirements, why would you force the weight of the entire process and slow down the delivery?  Skip the scoping document, skip the full requirements analysis, get the right people in a room to create an impact statement showing what will be touched so that everyone knows what needs to be tested, and get on with it.
2. What is the risk to the organization if this project does not succeed?
• If this is a low risk system with very little impact to the organization, why would you waste a lot of internal resources and time to create all the formal documentation?  Identify a minimum set of documentation that gives the team the information they need, verify with the sponsor that they are on board, and bang it out.  Don't slow it down.
3. What is the risk to the organization if specific features/functionality are not delivered?
• Again, if this is a system that is used by a small number of people, has very little risk to the organization, does not manage key data, then move it along.  Talk with the sponsor, find out what it means if specific features are skipped for this release.  If they are on board, get it done.  Maybe they don't need the features right away, maybe some of the features were wish list stuff that isn't needed to really get the job done.  Narrow the scope and provide the key features/functionality to the users.
4. What is the overall size of the team providing this solution?
• If it can be defined and worked by 1 or 2 people sitting in a room together, why would you waste putting the entire process in place?  Seriously, put the end user in the room with the developer and let them get it done.
5. Who are the end users of the system being delivered?
• If the system being developed is used internally, do you need all of the pieces of the lifecycle to be used to deliver the functionality?  I ask this question seriously.  Sometimes you do because the data being touched is critical or because the system being worked provides key data used to manage the place.  However, sometimes internal systems don't  need all the fluff.

Ultimately, you have to look at what is the risk to the organization - what data is being touched, how complex is the functionality being delivered, what is the impact if it doesn't get delivered or if it is pieced out over multiple deliveries?

Part of our jobs is to reduce the clutter and allow the team to get the work done.  As a Project Manager, you need to review each project that you're given and begin to make recommendations back to the Project Office and the Project Sponsor when you feel you can skip pieces of the lifecycle and certain artifacts.

Trust me, your Team will love you when you tell them that you can speed things up.  Look, the people that work on your teams know when stuff is being done just to click off a check box versus adding real value to the process.  If you can come in and show them that your stripping away the stuff that doesn't need to be there, that you're working on their behalf, you're going to get a lot more respect from the team.  They'll work harder and make your life easier.  However, if you continually tell them that they need to fill out this form or that form because the process demands it, you aren't going to get very far.

I would challenge you to go as far as formalizing the process used to reduce the artifacts and skip phases of the lifecycle!  The Teams that I work with have defined a process that we use up front and along the way through gating meetings where we can recommend specific activity or artifacts be skipped.  This gets presented to the Project Sponsor and decisions are made and documented about what will and won't be done through the following phases.  Reviewing this at each gating meeting allows us to adjust this decision based on new facts that present themselves during the overall project.

How are you removing the clutter within your projects?

Tags: Project Management, SDLC, Project, Management, Project Manager, Software Development Lifecycle,  Project Lifecycle, Project, Manager, Development
 
For more information on David L. Collison: LinkedIn Profile