Have you ever heard the phrase, “Death by paperwork,” or “Death by process?” Better yet, have you ever experienced either of these? If you have worked for any reasonable amount of time, chances are that you have. In this day of red tape and CYA, paperwork and processes have become the norm and they can really kill your project delivery date. It isn’t always enough to simply schedule time to complete these tasks. How about you look deep into these processes and determine their actual value and eliminate the ones that may be somewhat superfluous? After all, at some point, the work has to actually get done – and I’m sure you have plenty of it!
For those of you running a PMO with strict process guidance, please hear me out, but give me your thoughts at the end.
Here are a few items to consider:
- Define the project type. It is important to understand what is truly required to complete your project. Software development projects differ greatly from a BYOD initiative or an infrastructure refresh project. Differences may include architecture reviews or design documents that would be appropriate for one project but not another.
- Consider the actual size of the project. There are several attributes that must be considered here including number of end-users impacted to size of project team and of course, project budget and duration. A small project that impacts 100 users and lasts 3 months with a cost of $25,000 should have different document requirements than a multi-million dollar software implementation that takes two years.
- Determine actual requirements of the group you are working with. Business facing projects will typically have fewer process requirements than a typical IT project. At the same time, some business entities such as accounting or audit, may require additional processes. If the project doesn’t warrant a process for SOX compliance, for example, why even create a document for it?
- Simplify some of the documentation that you will use for every project. Project charters, for example, have a full gamut of length and complexity. In reality, the project charter really should be a simple document that gives a brief description of the project as well as a list of the high level roles and responsibilities that the PM would be accountable for. Anything else really belongs in other standard documentation.
- Make some documents standard. Think about a communication plan for a moment. What is defined in the communication plan? Types of communication with definitions of each as well as expectations that each project will have regarding all types of communications. When you think about it, most of these types of communications are the same across every single project. Team status meetings, stakeholder meetings, leadership meetings, status reports, RFPs, etc. will be the same. Sure there is some customization for each one based on the team and requirements, but create a well defined template that irons out each type and basic expectations. Don’t re-write every document every time.
It is time for the project bureaucracy to start swinging the pendulum the other direction a bit. It is possible and smart to cut out some of the formalities for some projects. If it is required, don’t cut it out, but make it a requirement if it has no value. Documents with little to no value that get created are simply expensive time wasters. Resist the urge to require a check box for every little thing. Here are some high level suggestions
Need to define but don’t go overboard:
- Charter – keep it simple
- Scope – sometimes a high or medium level scope statement is all you need. Detailed scope statements get very complex and can cause you to get lost in the weeds
- Schedule – build your schedule so that it is manageable. You don’t need every little detail documented in the schedule. If you aren’t careful, you will spend all of your day trying to keep up with the schedule updates and changes.
- Status reports – here everyone rolls their eyes. Often times status reports aren’t even read. Keep these simple – and automate some metrics for easy reporting. Hint: use the Unique Task ID in MS Project to export into MS Excel for simple, automated updates. You can also create categories in your financials to report high level metrics as well.
Make some plans standard
- Communication Plan – meetings are meetings – set expectations here for all projects and stick to it. Remember, sometimes a phone call can take the place of a meeting – meetings are expensive. If you don’t believe me … do the math yourself. I find it very interesting that certain level of employees have limits on the amount of money they can approve on an expenditure but anyone can call a meeting. If you are holding a leadership meeting that runs an hour . . . it can cost thousands of dollars just to have everyone paying attention to you.
- Change Control – Change processes are important, but are also the same for all projects in an organization. One document for every project will suffice. Simply reference that document in your project management plan
- Risk and Issue Logs – make a SIMPLE template and follow it for every project. This also helps leadership to see the same type of information across all projects.
Of course, there is much more that can be put here, but I’ll keep it simple myself and wrap this post up. Remember, sometimes, less is more. If you are mired in process, your project is slowly slipping away, or your life outside the office is. Either way, you don’t want that to happen.
Lead lean! Lead smart! Lead on!!
Have a great rest of your day!
I value your opinion and would love to hear from you. What do you think about lean project management? Please comment below.
Are you malicious? I would put good money on your answer being a resounding “NO” if you are reading blogs about leadership and teamwork. You might Look at it a little differently, however, after reading this, and I hope it will change you at least a little bit.
I have recently been a “victim” (for lack of a better word) to piecemealed data. What does that mean? Well, it means that when I ask other resources for data, I get bits and pieces of the data based on the specific question I asked. If I don’t ask the right question, I don’t get the right data. It can be very frustrating, at times, especially when that data is critical. I have also notice this over the years from other colleagues as well that just don’t want to paint the full picture. It is almost like they are wanting to leave things a bit mysterious.
Sure, I understand that management is often times bound by the constraints of “I can’t tell you yet” and I’m not talking about those instances even though they can be very frustrating at times as well. What I am really talking about are the silos of information that exist in corporations all across the world. Silos can be dangerous to a company. Why dangerous? Well, I believe that giving little bits of information can cause other teams to be counterproductive. It can cause them to go down a path of data mining to get the information that someone already has but is not sharing, or it can cause them to spend additional cycles thinking of the “best way” to ask questions so they get the right answers. Within the same company, a full picture should always be painted when the full picture is what is being asked for. Don’t make it sound as if you’re giving all of the information when you aren’t.
So, I ask you again, are you malicious? If you are holding pertinent information back just because it wasn’t specifically asked for, I say, yes you are. If you are not meaning to be so, then you might take a closer look at how you deliver information. If you DO intend to hold on to information for your own power play (remember, knowledge is power) then I urge you to change your ways because you are causing your company more harm than you can really imagine.
Here are a couple of things you can try:
- Ask questions to make sure you fully understand what is being asked of you.
- Be more open with the information that you have. Remember, good leaders help build others.
- If you do not have time to tell the whole story, give an overview and tell the person that you are only giving them a small piece of the puzzle they are asking for and schedule some time to give them the whole picture.
Thank you for reading! I’d love to hear your thoughts. Have you been a “victim” of of someone holding on to knowledge that cause you do go down the wrong path?
Have a great day!! ~Jim
How do you, as a leader handle heated conversations in your team? Are YOU engaging?
Differing opinions are a part of our daily lives. In fact, in leadership roles, they are essential to the survival of the teams we are tasked with leading. By this, I mean that utilizing different opinions or even different world views will allow us to avoid the damaging and often destructive results of groupthink. While we might think that life is great if everyone agrees with us, it all too often means that something is about to go horribly wrong.
The problem is that differing opinions can sometimes create tense moments during a meeting or even just during an otherwise calm part of the day. Let’s face it, there are many people out there passionate about their work and about their opinions. It is our job, as leaders, to keep that passion somewhat controlled and pointed in a positive direction. If the argument gets heated, or worse, the meeting, whether formal or informal, it needs to stop right then with encouraging words that all disputes can and will be resolved amicably. It is critical that all of our team members feel safe coming to work (emotionally or physically).
In the end, it is important for teams to have differing opinions but in a controlled environment. The biggest thing I can leave you with as a leader is to not engage in such heated discussions. If you get into a strong disagreement with a team member, you either need to take it to another, closed-door room or just table the discussion for another time when you both have had a chance to calm down and reset your passions. Keep in mind that it is possible that you DON’T have the best idea, be sure to set your ego aside too.
Different opinions are essential to business. Without them, we would all wear white shirts with blue pants, regardless of gender, age, race, or nationality. All cars would be white 4-door sedans with gray interior and all houses would be white with blue trim. We don’t live in any such society, not even the ones with the harshest of homeowner restrictions. That doesn’t mean we have to box our neighbor’s ears when we want to paint our house a different color.
The most important single ingredient in the forula of success is knowing how to get along with people.” ~T. Roosevelt
What tricks have you used to stop heated debates at the office? Comment below.
Project communications are perhaps the single most important aspect of your project management plan. It is also one of the most overlooked from a planning perspective. This could be because project managers have a tendency to think they know what to communicate to whom and when. The truth is, communication is something that has to be talked about and planned in advance.
The PMBoK Guide – Fourth Edition (A Guide to the Project Management Body of Knowledge) breaks communications management down into five sub categories:
- Identify Stakeholders: Identify all people and organinzations that will be impacted by the project as well as their specific involvement and impact on project success
- Plan Communications: Determine what each person or group actually needs to be made aware of and in what form. For example, you will perhaps send daily detailed communications to the project team via electronic communciations, but only a weekly wrap up via staff meeting to a project sponsor or executives
- Distribute Information: This means that you actually do what you said you were going to do in the previous item.
- Manage Stakeholder Expectations: Pay attention to your stakeholder’s needs. You don’t want to give them too much or too little information. Give them only what they need which may mean removing or even add to the information identified in step 2.
- Report Performance: Periodic analysis of baselines versus actuals during the project. This includes analysis of performace, risks and issues, work completed, upcoming tasks, summary of the approved changes, and others.
Communication is a critical piece of the project health. We are always communicating with our teams and other stakeholders. If we neglect to plan the communciations up front, it is almost guaranteed that something will get missed. When things get missed, we lose out on opportunities to make vital corrections, learn of a new direction, or even a pat on the back every now and then.
I know I have simplified things a bit, especially as they relate to the PMP exam, but for daily business, these are the basics. Sometimes, the projects are small and greatly simplified. This doesn’t mean that these steps should be overlooked. It merely means that the steps are that much easier to follow.
I use EVM (Earned Value Management) on all of my projects. The project stakeholders love the real-time look at actual progress acheived.
There is a difference in what percent complete really means . . . Do you want to know more?
If you don’t mind, please take this short poll so I can see where we all stand.