Thank you to all of those who have made sacrifices so that we can learn and have these discussions about project management.
Happy Memorial Day! Enjoy your weekend.
Thank you to all of those who have made sacrifices so that we can learn and have these discussions about project management.
Happy Memorial Day! Enjoy your weekend.
In my last post, I talked about learning from the aviation field and how they use automation technology effectively to fulfill their objectives. We are taking that and applying that to how we could use automation technology in project management (aka project management software tools) effectively.
You can read the first post here.
Let's turn to some practical lessons that we can apply:
Provide Training to Your Team, Managers, and Stakeholders
Can you imagine a pilot flying a new airplane without being thoroughly trained on the automation technology in that airplane? The consequences would be serious. Yet we provide tools of a sort to our project teams, managers, and stakeholders without the training for them to use the tools effectively. As I mentioned in the last post, people have to build a trust in the system. Training plays a big role in building this trust. Training should also be process-driven. In other words, most people do not need to know all the ins and outs of every feature in the system. They just need to know how to perform their job in the tool. That means that you do not need to send everyone through two weeks of formal training. But you can and should hold some informal sessions (such as brown bag lunch sessions) and produce some organization-specific documentation on how they should use the system.
Document and Understand Your Processes
Technology without a clear purpose just frustrates people. Technology should support your key processes, make them easier to follow, and provide insight into the execution of those processes. That means that you need to know what your processes are. And you need to communicate those to your organization. You cannot assume that everyone knows through some type of "tribal knowledge." You need to have a set of documents that details out the key processes that you expect people to follow, such as how to initiate a new project, how to assign staff to that project, how to submit status, how to obtain a client's approval, and so forth.
After that, you can look at your technology and how to implement those processes in the technology tools that you have. In fact, within your documented processes you could include steps on how to fulfill those processes using the tool. You end up with a set of "standard operating procedures" that everyone understands. Do you see the difference? This is far more effective then simply getting a tool because we are "having a problem with schedules slipping." After doing this, you may determine that you need to use the tools differently, that you need different tools, or that you need to simply train people on the proper way to use the existing tools.
Automation technology should not be complex. If there are a lot of steps that a person needs to follow to perform something in a tool, then it is too complex. Automation technology should do just that: automate key functions that would take a lot of time otherwise. This could include generating a report, collecting status, identifying resource overloads, and others. Your tool should make these key items in your process easier. Part of this means that you should not overreach and make your tools overly complex. Keep them as simple as possible. Said another way, set them up so that you can run your processes and get the information out of them that you need, but no more. Don't do things just because you can in the tool or because it is "cool."
Provide an Expert
Someone in your organization should be an expert in the tool. They should understand how to implement your processes in the tool, what the tool is doing, and how to extract information out of the tool (although everyone should understand this). They should be a resource for others that are perhaps new to the tool. If you have a larger organization, create a network of these people that can provide assistance to team members, and ensure the tool is being utilized properly. In other words, don't leave people to fend for themselves. And do not always rely on the vendor for understanding how to use the tool. This is going to be a key part of your processes so make the investment to have someone inside with in depth knowledge.
Technology in project management can be a valuable, game changing piece when implemented well. Try these lessons in your own organization regardless of the particular tool(s) that you may be using.
In the midst of doing some research for a post on the Flying Into Project Management blog on team interactions, I came across some relevant lessons to this blog on project tools. Specifically, I was looking at how the aviation field makes automation technology work in today's airline cockpits. There were some interesting insights, parallels, and lessons to how organizations can make project management software tools work for project teams.
First of all, what is automation? I am simply referring to technology that automates certain tasks. That could be a number of things such as finding out the current status, identifying problems, generating alerts, seeing where you have been, visualizing the upcoming plan / path, etc., etc.
Automation should have two goals:
In other words, our automation tools should always enable us to know what the real state of our projects are, and they should reduce the work that is required for us to know that state.
There are some common responses that people have to automation technology:
That means that automation technology needs to:
In a follow-up post, I will discuss some practical lessons as to how to make automation technology work in light of these insights. Please note that much of this insight came from the source www.crewresourcemanagement.net.
In my last post, I discussed the issue of "garbage in, garbage out" in our project management software tools. In other words, if we do not have good data going into the tools, we will not have good data coming out of the tools. And that is a problem, since retrieving good data is a fundamental reason to have a tool in the first place. There are a variety of causes for this that we discussed in that post.
Fortunately, there is hope. Organizations have overcome this problem and produced a useful tool with useful information. Here are seven ways that you can overcome this problem in your own organization:
1. Make it public
Collin wrote a comment on a previous post on the importance of visibility. Don't hide the information in the system. Make it visible to everyone. This produces natural accountability. Who wants to be the one that is "holding up the system" and whose area is clearly lacking with input into the system?
2. Use it
If you do not use the information in the system, why would anyone take the time to accurately enter that data? Do not expect people to do so. However, if you consistently use the data and expect the data to be accurate, people will start to realize this is serious and will enter the right data. For example, instead of asking people to write up a report and email it to you once a week, insist that they use the project management software tool.
3. Implement Accountability
There has to be some level of accountability to use the tool. If there is not, many people will do what is most comfortable: doing things the way they have always done them. We have discussed this more than one time in the past and so do not need to rehash this here, other than to re-iterate that accountability is a key component.
You cannot expect people to enter accurate data if they do not understand how to enter accurate data. They may simply be lazy in not entering accurate data (or no data). But they may also be sincere and simply do not understand how to enter the data correctly. Or they are reticent to use the system to enter data because they do not understand it. This is where training comes in. Hold some brown bag lunch sessions that cover the process (not the features) that you want them to follow.
5. Set expectations
Expectations can be a wonderful thing. If I expect my kids to do something and I act that way consistently over time, they will often (not always) rise up to my expectation. If I do not raise my expectation for them and act accordingly, they will almost always revert to the lowest common denominator. I believe the same is true for our project teams. If you set the expectation - i.e. that the important information you use weekly will be pulled from the project management software system - you inherently raise the bar. But you have to act appropriately. Meaning, you go to the system and expect the information to be there. That is just how things are done. I am not saying that is a magic bullet and it is that easy. But I am saying that plays a key part in raising the bar for your organization. Your organization (whether a corporation, company, group, department, or team) will only match the expectations that you have for it.
6. Understand it is a process, not an event
Getting accurate, good, actionable data into your project management software tool is a continuous process, not a one time event. You need to continuously do these things, talk about it in your meetings, and make them an integral part of your processes and culture.
7. Understand it is a management issue, not a technology issue
In most cases, getting garbage in your project management software tool is not a technology issue. It is a management issue. It is a matter of managing the team and organization so that they indeed do enter quality data into the system.
Choose at least two of these things to work on and pay attention to the level of quality in your project management software tool.
Most of us have heard the adage, "garbage in, garbage out." It refers to the fact that the information you get out of a tool is only as good as the information you put into the tool. If people enter in garbage (bad information), you will get garbage out.
I did some searching and came across reams of sites, information, reports, etc. about data quality. Much of that is focused on IT and how IT can help to ensure data quality in company databases.
I want to talk about data quality in our project management software tools from non-IT folks. If I were to ask you, what is the number one reason that you even use a tool in the first place, what would be your answer? Because it sounded like a good idea? I would dare say it is to get accurate information, anytime, in order to make good decisions and take action. Why else? For example, there is no reason to put a project schedule in a tool, unless you want to pull information out about it to figure out what tasks need to be done, what tasks are falling behind, or to see someone's workload across this and other projects.
If that is true, then this issue of data quality is huge. We have all seen symptoms of this:
This creates a big question of why you have the tool in the first place? Fortunately, there are ways to improve the situation and achieve the data output that you need (we'll talk about that next).
In the meantime, I am curious. What other "symptoms" have you seen at your organization? Leave a comment, or email firstname.lastname@example.org.
This morning I wrote a post about workload management in the Flying Into Project Management blog, where we delve into lessons that project management can learn from the aviation field. Every once in a while I will cross-post on this blog and I am doing so now.
This post talks about one of the factors in improving our team management and efficiency by looking at the concept of workloads. Since teams are a critical piece of our projects and the resources we have available, it is a relevant topic.
You can read the post here.
"Everything rises and falls with leadership", according to John Maxwell. Does this include our projects? Of course it does. I would say it is especially important in project management. Why? Because project managers often do not have positional authority. In other words, they are tasked with managing a project without a "position" that actually has authority over the people working on the project. And yet it is vital that the people working on our projects follow us. Say again??
What's the answer? Leadership. Leadership does not require a position. It simply requires that you lead well and that people are following you. If someone is not following you, you are not leading.
Here are some interesting points that John Maxwell made at the leadercast event I attended last week:
1. When you lead because of your position, people will follow you only because they have to. Even if you do have the right "position", you want to go beyond this...way beyond this. Project managers rarely get this authoritative position anyway.
2. When you develop relationships with people, they will follow you because they want to. Sincerely building relationships with people, in my experience, is one of the best ways to begin to develop good leadership with your team.
3. If you are achieving results and being productive, people will follow you for what you have done. If you, as a project manager, are achieving things and helping the team win, people will follow you.
This is just barely scratching the surface.
When all is said and done, your position and level of authority in an organization does not matter. What matters is your level of leadership. Are you leading in a way that people will follow you? Are you developing your leadership skills? This is how you gain influence with those in your project organization.
I attended the Chick-Fil-A Leadercast last week. It was a great time to indulge in the topic of leadership in our lives and our organizations. Although this is a project "tools" blog, if you will permit me I will share something I gleaned from the event.
Frans Johansson spoke on the topic of innovation. Innovation is tremendously important in today's organizations. We must innovate or we fall behind. It doesn't matter what our situation - whether we are responsible for developing products for external customers, or whether we are behind the scenes serving our "internal customers." Even personally, we must continue to pursue innovative ideas and try innovative things.
One key point that Frans made was that many innovations are not brilliant ideas, but simply the result of trying more ideas. Why? Because we are horrible at predicting which ideas will work. People kept trying ideas until they found one that worked. They didn't give up. They persevered. They didn't let failure stop them. Examples abound of this tenacity, including Abraham Lincoln, Thomas Edison, and many others.
It is easy for us to sit and be comfortable with the way things are in our project organizations. Let me encourage you to pursue ideas. Pursue ideas that can take you to new places as an organization, as a department, as a person. And don't give up. Make it a lifelong pursuit of pursuing new ideas. And see what happens.
I just completed a new whitepaper on understanding the 5 purposes of technology in project management. The idea behind the whitepaper is to provide a broader perspective on the role that technology (especially project management software) should play so that organizations can achieve much greater value from it. Often times today, I find that organizations severely limit themselves with their perspective for technology. For example, they look for a project management software tool that can "do Gantt charts" or a "task list." There is nothing wrong with that except that it limits what you can do with even the most basic technology.
This whitepaper was derived from a series of posts on the Flying Into Project Management blog.
This whitepaper will be published shortly. You are the first to see it. I encourage you to download and read it and provide me with your feedback to email@example.com. I would love to hear it.
Continuing on the theme of non-software tools for project management, it came to mind that there is one tool that all of us have, all of us use (hopefully), and all of us need to nurture. And that is...our brain. Now that sounds like an introduction to a third grade science class, but it is true. We all have to make good decisions, remember things, stay attentive, and solve problems. A good software tool will support those functions, but no software tool will ever replace those functions. It only makes sense to develop our minds to be effective tools in our project management roles.
Here are some things that I thought of to help us in that endeavour:
Taking care of ourselves physically (this does nothing but help the brain):
Pushing ourselves mentally:
I even found a website called Headstrong that produces games to help you sharpen your brain skills, such as memory, attentiveness, problem solving, etc. You can check it out at http://www.headstrongbrain.com.
At the risk of sounding like a third grade science teacher (yes, I have a third grader), I am after using every tool at our disposal to become great project managers. If we can work at making better decisions, solving problems more quickly and effectively, and remembering more, we will be that much more effective.