Long long ago in the 1990's, the mantra for a successfully run project was simple and at the same time very complex. Get a robust set of requirements, so you knew what you were going to need to deliver to the client in 18-36 months. The challenge was always getting a good set of requirements, but if you could, then you would roll in the business analysts to document them, estimate them, and the sit-down and optimize your schedule. We would use critical path analysis, resource leveling, pert analysis, etc. The goal was to minimize the path and optimize the resources to find the shortest and least costly way through the maze of thousands of tasks with dozens of people. We then rolled these up into portfolios of projects and worked to optimize all of the projects against each other. Again, the goal was to balance hundreds of thousands of tasks against a resource pool and optimize what could be delivered in an optimal way -- balancing our risks vs. reward.
Unfortunately, the world changed along the way, and this approach now only fits a smaller set of projects every day. In fact, this may have been a fairy tale all along. Very few projects are ever really considered overly successful using this approach. Instead in the real world, you had customers who struggled to tell you what they wanted until they could see it. Often, they would see the work near the end of the project. You had requirements changing faster than you could deliver them and there was always a senior leader in the mix that wanted something that felt like a miracle to pull off. This is when the backdrop of the agile approach picked up steam. It recognized the reality of the real world and instead of fighting that reality, it embraced the chaos. The idea was pretty simple really. Working software (this is where the idea started) trumps documentation. There was a recognition that you didn’t know everything so why pull your hair out? Embrace it and get things in the customer's hands early and often. Clients can then see what it looks like and can then define the next layer with you. Yes, the traditional sequential task management based plan and schedule were replaced with a learn, do, learn model.
The results of taking this agile or adaptive approach to delivering software proved to get better software, faster, and in some reduces cost. Not because we have wrangled the chaos but because we have embraced it. By recognizing that we can only know and control what we can, we have allowed team members to focus on what they can deliver. The agile approach made it easier for them to get rapid feedback on what they have built and as a result, they understand the customers’ needs better. But this brings us back to the traditional project management approaches. They are not about embracing chaos. They are about trying to eliminate it. Create certainty, optimize, and you will be successful the traditionalist tells us. If the customer co-operated, the world would slow down; the chaos would stop we would have been on time, budget, successful! But how many projects today do the traditional approach fit? 80% maybe? It doesn’t matter if it’s software development (where the ideas started) or marketing campaigns. The one thing that you can count on is that the world is moving faster every day and the complexity of work is ever increasing.
Companies are now trying to figure out the best way to take the ideas and lessons learned in a subset of projects that have been running in a much more agile or adaptable way and use them organization-wide. How can our entire company embrace the ideas of being nimble, agile, adaptable? Entire industries are being disrupted every day by the companies that bring to market new adaptive approaches. Uber is replacing the taxi industry, Airbnb is twice as valuable as Hilton, Google and Facebook have completely changed how news is delivered. Today there is someone in a garage, college dorm, or a boardroom who is mapping out a plan to fundamentally change your industry. The winners of these challenges are the companies that will react fast enough to these opportunities and threats to stay ahead of them. To do this the winners of the future have to be able to adapt at a moment’s notice. It is in this backdrop that companies are in a race for their life. Either become adaptable or die.
At Coras we see the way to get to a fully agile or adaptive organization is by recognizing that the old way of doing things aren’t fast enough. Optimizing resources in a linear sequential way assumes too much stability. Instead, we believe that you should organize for chaos - embrace change. Organize your teams in ways that you all learn together along with your customers. Getting started is far more important than being right. Do short planning cycles for short work cycles. Bring the entire team into the planning. Collaborate as a team and ensure everyone knows how they fit into the whole. Reuse light-weight best practices, processes, checklists, etc.; ensuring consistency where possible. Assign work out, track it, and learn from each cycle that you complete. This process works in almost every team across nearly every function. Plan, Do, Learn, and then repeat. This is the new way of looking at “projects” or maybe a better way of saying it is “this is the new Work Group.” There isn’t a defined scope, start date, and some delivery date way in the future. Instead, it is small work packages being planned, done, and delivered almost daily. In this new world, flexibility is way more important than optimization. The traditional project management approach is ready for its life in the Project Management museum along with many other business practices of the past.