What does a Project Manager need to know about Project Management?
Don't worry, this isn't a job interview; it's okay to say "It depends."
It seems like, once you get past a core set of skills, there is a lot of variation, between companies, when it comes to what is expected of a Project Manager. I've also noticed a lot of variation in what is expected of a Project Manager from different employees within the same company. A starting point might include the following:
The longer you work as a Project Manager, the more important it becomes that you understand the nature of work and how it can be accomplished. You also need to understand the culture and structure of the organization you work in to choose the best approach to successfully accomplish the work to be performed. Here are some areas to study:
As a PMP, I feel a little obligated to say that you need to know the PMBOK, but I also feel the need to point out that it is the PMBOK Guide, emphasis on 'Guide.' There are also other approaches, such as Prince2, that may be more relevant to your career. Knowing what is relevant to your career is more important than using the topics I've mentioned as a checklist for things you need to know.
The point of having a tool belt is to be able to know how to use the tools you need based on the situation you are in, not to use every tool you have. So, here's a question for the rest of you - reply in the comments section - what else, in your experience, do Project Managers need to know?
Have you ever had a really good idea that you were excited about, that you couldn't wait to start, only to have it go nowhere? I've had more than one hobby that went into limbo and became an "interest" because it was a good idea, but the timing wasn't right. I'm sure I'll get back to one or more of them, but now is not the time.
Have you noticed that we have similar behaviors at work, often with one difference? A good idea becomes a project and resources are assigned to it, but when it loses priority it never actually stops. Nobody says, "This isn't a good idea right now." Instead, people work on it when they have time, assuming it doesn't impact anything. Don't get me started on multi-tasking… but multi-tasking isn't the only concern. Activities involved in both testing and implementation tie up people and resources, and not just those performing the work. A desktop software implementation can distract people working on other projects, as well as resulting in issues that can stop work until they are resolved.
This post is only partly about organizational multi-tasking and project prioritization. It's also about efficiency, or at least the illusion of efficiency.
My work is primarily in IT, so there will be an IT focus in what I write, but I will try to tie it back to the business, as well.
IT is expected to be efficient. It often feels like people think efficient IT means working on all requested projects and getting them all done on time and within budget. That doesn't feel very efficient to me. Can you see the connection to "good ideas?"
A company can have employees working on a lot of projects. Some strategic, some compliance enabling, others required to keep the lights on, and then a bunch of good ideas. The company can hire more people and buy more equipment to keep everyone working efficiently on all of the projects. Eventually, however, there will be conflicts. A natural bottleneck occurs with testing and implementation. When you have interdependent systems, your dependencies limit the amount of separate changes that you can effectively test or go live with at any given time. If you really want IT to be efficient, you need to insert a bottleneck in the decision-making process in order to limit the amount of work in the project pipeline to match the amount of output your organization is able to effectively deliver. (Think of Portfolio Management as one step toward making this happen.) Over time, you may be able to enlarge the testing and implementation bottleneck, at which point, you will be able to increase the amount of work in the pipeline.
So far, we've just been talking about IT projects. Now, consider a company, like the one I work for, that has global markets. This means global marketing projects and global sales events that also impact the web, mobile, CRM, and ERP systems, among others. The windows for testing and production implementations just got a lot smaller. Should these activities be considered as part of portfolio management?
Is that good idea you're working on a good idea right now, or would it be a better idea to work on it when it is a better fit with other priorities your organization is pursuing? Or, not at all? Does being a good idea automatically mean that it deserves to be executed?
I'm currently listening to The Goal, by Eliyahu Goldratt and Jeff Cox, while I commute to and from work. I'm about halfway through it and, so far, it reminds me of some problems we experienced load testing our ERP and sales systems.
We encountered login failures during load testing, where we hadn't before. A little digging revealed that recent performance improvements had sped up our submit times but we hadn't accounted for the impact on other processes. As a result, we experienced failures. Our attempt to become more efficient made us less efficient because the improvements we made ran into downstream processes which choked due to greater volume than anticipated.
One possible interpretation of the message of The Goal is that overemphasis on efficiency when doing something can lead to ignoring the reason why you're doing what you're doing, in the first place. You basically end up failing efficiently, but that is a little oversimplified. A bigger concern is whether or not you are focusing on the right efficiencies. It doesn't matter how efficient your production is if you're not selling anything. From a software development perspective, it doesn't matter how efficiently your team is developing code if they're not delivering code that the customer wants.
From a project management perspective, are your projects helping your company achieve its goals? A project can be on time and within budget, yet still do nothing to help a company achieve its goals.
Don't worry, I'm not about to segue into Portfolio Management. I could, but if you're not doing Portfolio Management now, you're not going to automagically be able to start once you finish reading this. You can, however, examine your products with the critical eye of The Goal (with the caveat that I have not finished the book, yet). Does your project help your company meet its goal through some combination of reducing inventory, reducing operational expenses, and increasing cash flow?
What about you? Have you read The Goal? If so, what insights did you gain from it, as it relates to project management?
Innovation and project management go hand in hand. If you're innovating, you probably have at least one project on the burner. So, why is innovating so much harder than project management?
The easy answer is that, usually, project management is a highly structured, well documented process, whereas there does not seem to be a magic formula for successful innovation. A project has a point at which it is done, by definition. Innovation evolves. Scrum-based flavors of Agile seem like strong candidates to use for a project management framework for innovation, but will it still look that way when you peel the onion and see what's hiding inside?
I know, the onion analogy is old, but it is appropriate, although slightly flawed. What makes it appropriate is that there is more to innovation than what you see on the surface. Each layer may be similar to the one before it, but without the underlying layers, there's not much to it.
I'm seeing a parallel between Agile and onions, now. Please, make it stop!
My point is that, like the outer layer of an onion, an innovation effort does not stand alone. There is a core of culture, people, processes, tools, and data that all affect a company's ability to innovate.
I'm going to borrow a concept from Agile to describe a common challenge to innovation: technical debt. In Agile, technical debt refers to old or poorly written code that needs to be refactored in order to deliver a desired feature. From the perspective of innovation, I am using this concept to represent systems, software, and processes that need to be changed before an innovation can be successful. If you ignore this technical debt, you risk failure, and we're not talking about a software release, any more.
If not addressed properly, technical debt can become part of a painful cycle. With software used in multiple markets around the globe as an example, let's say it's been several years since the last major upgrade. The required downtime wasn't feasible because of global sales events, which is how your company earns revenue. Your company has reached the point where the software cannot reasonably support the changes you want to make. You either need to perform the upgrade, or implement new software. Either way, there will be downtime. It takes close to a year, but you make the change and start innovating, only to realize that you've started the cycle over again and 5 years later you have to make the same decision; upgrade or replace your software.
The flaw in the onion analogy is that innovation is not occurring on the outside of the onion. The growth of an onion occurs in its core, forcing the outer layers to stretch and grow.
If you're expecting me to compare the core and outer layer of an onion to IT and the Business, prepare to be disappointed. This mindset is a factor in why some innovation efforts struggle. IT provides the business with functionality; the Business provides IT with purpose. It should be a symbiotic relationship, where both stretch and grow together, but it is often hampered by those that view it as a parasitic relationship, both in IT and the Business.
Once upon a time, I was an IT project manager at a claims processing center. The Business was frustrated with the service not provided by IT, even though the real problem was due to software that the business forced upon IT. IT, feeling like it was performing miracles just keeping the software running, expressed that the Business could not function without IT. One day, the software crashed. Hard. After a couple of days with no real progress, the Business began processing claims by hand. It was much slower than normal, but they made it clear they could function without IT.
And with this adversarial relationship, it took significant time, effort, and money (to replace the software and fix relationships) before innovation could begin again.
Back to my original question, "Why is innovating so much harder than project management?" Because it's not just one thing. Innovation is many things happening at once. Good project management can help an innovation effort be successful, but unlike an onion, if you're only looking at the surface, you really have no idea what else is going on. All parties need to realize that business and technical innovation go hand in hand. If you try and accomplish one without the other, you're missing the big picture.
It's that time of year again. You know what I mean. The time of year when you try to find your project team and ask yourself, "Why did I commit to a deadline between Thanksgiving and New Year's Eve?"
For those of you who don't work with US teams, you probably have a similar experience around other holidays. I worked with a team located in Europe and found that August was not a good time for deadlines. Golden week, in China, is not the most productive time, either. Fortunately,we can account for these events in our schedule.
I'm finding that a bigger challenge is trying to run a distributed agile team with three sets of holidays. The running joke is that Argentina is always on holiday and Peru never gets a holiday. As long as the developers don't have urgent questions for the product owners, over US holidays, their productivity is not greatly affected. It's not actually hard, it just slows the work down, and we need to coordinate our release dates a little more carefully.
I enjoy what I do at work, and I also enjoy being able to step away from it, over the holidays, and focus on things other than project management. That's where I'm at, this year. Unlike the person in the video below, when I step away from work for the holidays, project management the last thing I want to think about (except for my blog, of course). You don't have to watch the video; it's just six minutes of someone's preparation for and execution of Thanksgiving, shown in Jira. Masochist.
If this is you and your holidays, I hope it's by choice. If I had to use project planning software to schedule my vacation, I would look forward to going back to work so that I could take a break. My only plan for the long weekend about to start is to smoke a turkey. Deboning it is a chore, but it is soooo worth it.
Whenever your holidays are, I hope you get to enjoy some combination of good food, good friends, family, and doing things you enjoy.