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.
I thought I'd take a moment and think about something other than election coverage.
I'm not sure if it's cause, effect, or altogether something else, but optimism and vacuums seem to go hand in hand. Think about your last project, for a moment. How accurate were the estimates given in the early stages of the project? If you have even a little experience in project management, you knew they weren't going to be accurate, but you may not have identified all of the reasons why.
The obvious reason is that the earlier it is in a project, the less you know about the project. A factor that often gets overlooked is everything else going on in your organization. You can know that it will take six months to complete the project... if that's all anybody did. How long will it take when you account for everything else going on? Planning projects in a vacuum happens all too often, and it results in optimism about how much work an organization can complete in a given amount of time.
We're all familiar with the concepts of effort and duration, I hope. If you want to know when a task can be completed, you need to know how many hours it will take for the assignee to complete the work, but you don't stop there. Next, you need to determine how many days it will take for the assignee to find the time to perform the work. I'm sure I'm not the only project manager who has seen a task that only required two hours of effort take more than two days to complete, for legitimate reasons.
Tasks are to individuals like projects are to organizations. There can be unknowns that make it difficult to estimate the "organizational effort" of a project. All project managers deal with this. We also need to understand the "organizational duration” of our project, taking into account the other projects and activities (priorities) our organization is pursuing that could affect our schedule.
If you think that this is starting to sound like portfolio management, you might be right. If your company is effectively managing a portfolio of projects, instead of running multiple silos of projects that, surprisingly overlap, you are doing better than many other companies. This is the vacuum and optimism I'm talking about. When we plan our projects in a vacuum, our estimates are basically blindly optimistic.
What can we do about this situation?
Don't run out and buy portfolio management software. Throwing a tool at a problem, without at least minimal analysis, just creates another way to fail. There are three aspects of problem solving that need to be addressed, in order. They are:
You won't solve the problems associated with optimism and vacuum-based estimates without the right people. You might be able to deal with this approach internally, but don't ignore the value of a third party facilitator or coach to help guide the change.
As you're getting the right people involved, make sure you all agree on the problem that you are trying to solve, then start identifying gaps in your current processes. From there, you can identify any additional processes and tools you may need.
Simple, right? Okay, maybe not as simple as I make it sound. You may not need a robust portfolio management system. Alternatively, you may need one, but not be in a position to implement one. Your mission, should you choose to accept it, is to gather the right people and figure out the best way for your organization to break away from optimism and vacuums.
When everything is a priority, nothing is a priority.
I've been saying that for over a decade and had no idea it was an actual quote, by Simon Fulleringer. I'm not claiming it was me. I just thought it was one of those things that was inherently true and often overlooked. It's also a sign that priorities probably need to be addressed. That is where I find myself.
I've been trying to do too many things for a while, now, and not gotten very far on any of them. The impact to my blog is that I am going to start posting every two weeks, instead of weekly. As I will also be cutting back on other activities and using my time more effectively, or trying to, anyway, this should give me time to finish one of the books I've been planning to post on - The Agility Shift.
My plan is to post more content about making an agile transformation, not just about adopting agile practices. I'll also post about some of the personal projects I am working on, and will continue to give updates on my agile team, at work. And, of course, anything else project management related that comes to mind.
Speaking of my team, we had our first formal retrospective, today. One of the things that was identified was how valuable the communications tools we are using have been. We've got developers in three different countries, but they are in regular contact with each other in spite of time differences.
The team is all on the same page with regards to improving our definition of ready. We're going to make a conscious effort to examine our stories and determine when more detail is needed in the story before putting it into the sprint, and when we just need the appropriate conversations to take place. There needs to be enough detail to estimate the work without BDUF - big design up front. The conversation is key.
Back to priorities. It's not that you're not important, but I have other priorities that I need to take care of tonight. See ya' in a couple of weeks!