Published on: February 17, 2020
Introduction to modern business project management
ryan quintal 5uWsTnU0NZE unsplash

This introduction to project management explores what project management means in a modern business environment. This article is not about running major construction projects, nor is it about delivering major infrastructure projects, such as HS2 or Crossrail. It is not about planning to put humans on Mars. No, this is about the type of project management that happens inside modern businesses. We are going to look at a simple case study that explains what project management looks and feels like and how it makes a real difference to organizations and how they operate. Our story looks at the challenges of delivering inside a growing online store called The organization may not actually exist, but the story of project management plays out in organizations of all shapes and sizes, every hour of every day, everywhere around the world.

small cult culture logo - Introduction to modern business project management

Delivering at

8bit star trek t shirt - Introduction to modern business project management was the brain-child of Steve and Aaron. Whilst at University, they were part of a community that enjoyed role-play games involving space-marines, knights and warlords. They discovered they could make a living selling painted figurines to others at their university. Over time, they added online sales, expanding their business rapidly.

Business was good, and the organization evolved from something that they operated from student digs to an organization that employed people with titles such as ‘marketing manager’ and ‘head of logistics and warehouse’. They had a contact center committed to delivering their famously high standard of customer care and an HR manager who championed fair remuneration for the hard work that was expected of everyone who worked there. In IT, there was a team that managed the internal technology, but also a small team of software developers who maintained the website and worked hard to respond to changing technologies and user needs.

Everyone knew how the organization worked, and which department did what. Bar the occasional hiccup, things ran very smoothly.

But there was a problem. Sales had stagnated over the past 18 months and the board decided to expand their product line into clothing. This seemed like a simple step: they had a loyal fan-base and an online store-cart system. All they had to do was add t-shirts and hoodies to the mix. The marketing team was excited. They got to work straight away to discover what products they believed would sell and to pull together a plan for the marketing launch.

But outside of marketing, there was less enthusiasm. Teams saw challenges and couldn’t see how the business would make the change work. Customer care lacked information to share with customers; logistics had no idea how the additional stock would be managed; and the web developers, who had optimized the site for selling figures rather than clothing in various sizes, couldn’t see the change happening any time soon.

The board was frustrated. They believed in the idea, but it was quickly becoming apparent that the work needed to turn the idea into reality was too big for any single department to deliver. The marketing team got frustrated at the lack of progress in other teams, whilst elsewhere in the business, people simply carried on doing what they had always done, the way they had always done it, because the new idea seemed doomed to failure and wasn’t worth putting the effort in. At the regular executive board meeting, it was the CIO who suggested a way forward: “What we have here is a project that cuts across each of our teams. We should hire in someone with the specialist skills to define exactly what needs to be done, plan it and coordinate delivery”. The COO agreed, adding: “We’ll need someone who is a good communicator too; someone who can make sure everyone knows what is happening every step of the way. I don’t want any surprises”. It was settled – they would hire a project manager. As the CIO knew the most about project management, it was agreed that she would be responsible for recruiting the PM and getting the project up and running.

Hiring a Project Manager

Sarah the CIO sat staring at a page. She’d worked with Project Managers before, but this was the first time she’d hired one for her team. She did what any good CIO does when they get stuck: turned to Google. A quick Google search threw up several suggested project manager profiles. Sarah spent several hours reviewing them and selecting elements that she believed were a good fit for what was crying out for. When she was done, she looked at her list of attributes:

  • Excellent organizational skills, to plan the use of people and resources to meet deadlines;

  • Strong interpersonal skills, to inspire, motivate and lead a team;

  • Good communication skills, and negotiation skills (good at managing expectations);

  • Ability to hit the ground running and make good decisions under pressure;

  • Good at estimating and forecasting progress (predictability);

  • Experience of delivering a similar project, in a similar organization could be an advantage;

  • Evidence of a commitment to learning relevant skills (Project Management Certification and evidence of continuous personal development).

Sarah smiled. If she could find the right person to join the team, she’d be well on her way to making the project a success.

Introduction to Project Management

Sarah felt she had struck gold hiring Jez. As well as being PMP certified, he had worked in small online companies previously. And best of all, he was a big Warhammer fan. He introduced a simple Business Project Management structure with four sections: Initiating, Planning, Executing and Control, and Closing.

A business Project Management structure with four sections: Initiating, Planning, Executing and Control, and Closing.

Business Project Management: Initiating, Planning, Executing/Control, and Closing

Jez started with Project Initiation. There was some initial push-back from the marketing team, who felt that the project was already well underway and this felt like a backward step. But with Jez’s calm demeanor and Sarah’s full backing (she was now, in Jez’s parlance, his ‘Project Sponsor’), he managed to get all of the key players into one room. He introduced something called BOSCARD, a mnemonic that, despite being oddly hard to remember, helped the team collaboratively agree on a Terms of Reference for the Project. The workshop was not without its hiccoughs. At one point Jez asked whether there was a business case for the project, a question that simultaneously earned him appreciative looks from the financial controller and daggers from everyone else. “We don’t need a business case, we already know it is the right thing to do”, came their response. Jez couldn’t help but think they were trying to initiate some kind of Jedi mind trick on him. It wasn’t going to work.

Jez explained. If you don’t have a business case, how will you know the project has been a success? “As project manager, I will be able to tell you how much you have spent and whether you have delivered everything you planned to deliver, but 6-12 months after the project is done, you’ll want to critically assess the success of the project. And at that point, it won’t be about milestones and deliverables, it will be about whether we achieved what were shooting for upfront.”. Everyone agreed that he was right, and further sessions were hastily arranged.

Despite being hard work to produce, the business case and the terms of reference proved invaluable. They were used by Jez to introduce people to WHY the project existed, and WHAT benefits it was setting out to achieve. Jez took the time to share this news with everyone connected to the project (people he referred to as project stakeholders).

Planning was where things got challenging. Despite everyone insisting the project was simple, it felt to Jez that everyone was only seeing a small part of the bigger picture. He explained this to them using the analogy of a group of blind men coming across an elephant for the first time (link in case you are unfamiliar with it: He organized a planning session where everyone could articulate the work that would need to be done on the project, and build what Jez called a Work Breakdown Structure with post-it notes on the office wall. When it was done, it looked like an organization chart, but detailed everything that would need to happen, from finance changes, warehouse modifications, to website changes and changes to the staff bonus targets.

People Deliver Projects

For the first time, the whole team could see the entirety of the task ahead of them. There was quiet in the room for a moment, before murmurings rose about how much work there was, how it was ‘too much’ and how they ‘couldn’t possibly get it all done’.

Jez looked unfazed. He’d seen this before. “Have you heard of the Kübler-Ross model?” he asked. He went on to explain the common cycle of emotional responses during a change project, from initial excitement and energy to disillusionment, to finally, improved happiness and success. “This is exactly what is happening now, and it is what will happen to your teams during this project”. He went on to explain to the project team and senior leadership team how they had an important part to play in helping the rest of the organization on the journey, through frequent and relevant communication, consultation, and respect for people’s positions and beliefs. After all, he said, “No matter how many Project tools you may have, it is people who deliver projects”.

Warhammer Kubler Ross - Introduction to modern business project management

Agility to manage complexity

Given the size of the project, and their lack of experience delivering anything like it at previously, Jez advocated an agile approach: the team would focus on iterative and incremental delivery, rather than trying to deliver everything as one big project. He introduced the team to The Agile Manifesto and the 12 principles that underpin it. He explained that whilst it may take longer to deliver absolutely everything, the approach would allow them to deliver some of the project faster, whilst giving them more flexibility to change approach along the way. Initially, Sarah had some concerns. She’d heard stories of arguments in the software delivery community about two different approaches to delivering projects. She asked whether it was better to deliver with Waterfall or Agile. Do Both! was Jez’ response. He pointed her to an article at, advocating a blended approach. He then went on to explain how it was important not to get fixated on any one approach. Rather, take the best ideas from both and adapt them to the unique environment at Cult-Culture. We need to rise above the waterfall vs agile debate, he said.

There was some confusion so Jez took the team back to the wall with a fresh set of post-it notes. “I don’t see how another Work Breakdown Structure will help”, grumbled someone. But this time, Jez introduced a concept called Story Mapping. Using post-it notes, they quickly mapped out the end-to-end processes that needed to be created across the business to support the change. But once this was complete, Jez encouraged the team to create customer and user personas to represent the types of people who would be engaging with the processes. Once created, he made them pick one simple persona and encouraged them to identify the smallest number of post-it notes that could be used to fulfill the needs of the person in the persona. It took several attempts, but after a while, the team had established that they could sell a limited run of tee-shirts (large size only) with only minimal changes to systems, and by using storage space in the corner of the office where the Christmas decorations were normally stored. It wasn’t groundbreaking, but everyone quickly recognized that this small, thin slice of the solution could be delivered rapidly with minimal effort. This would allow them to see whether clothing would actually sell, and start generating some user feedback. The marketing team was excited once again and started planning how they would solicit customer feedback and feed it back into the project team.

Depending on the outcome from the first slice, the next iteration could focus on broadening the product line, improving the supply chain, adding sizing options and automated returns policies or even something entirely different based on user feedback.

A New Normal

The launch of a single tee-shirt was low-key. Sales quietly went live on the site on a Tuesday evening. Sarah recalled it was raining that night, but the whole team had stayed late and celebrated their first step into selling clothing. The tee-shirts sold out quickly, and the marketing team gained valuable insight from customers on what they liked. They launched a competition for loyal customers to design an exclusive cult-culture hoodie. Again, this sold out rapidly.

Jez juggled several different styles of management. For the physical changes to the warehouse to handle the new stock, a traditional business project management approach was used with careful up-front planning. He was reminded of his father’s advice from his years as a carpenter: Measure twice, cut once. With such an expensive investment, it was important to take time to get the planning and design completely right before starting the building work. Other parts of the project continued with an agile approach. Changes to the website could be deployed rapidly and to a small percentage of site visitors. This meant changes could be deployed faster than ever and rolled back in an instant if ever there was a problem. Whilst Agile is generally seen as an IT software project delivery approach, it was adopted by the marketing team for their campaigns, and by HR for managing improvements to their human resources systems.

Six months from when the project had started, Jez called the team to a final meeting. They reviewed the Business case and the Objectives they’d set themselves in the project Terms of Reference. It was time to complete the final phase of the project: Closure.

With Jez at the helm, the team reflected on what had gone well, and what lessons could be applied to projects of the future. Then they ensured all the outstanding actions were handed over to operational teams. Finally, Sarah agreed to take responsibility for reviewing the business case in a further 6 months, to reflect on whether they had hit their sales figures. Based on the early results they were seeing, the team was confident they would be successful.

The business made the decision to keep the agile teams in place even after the project closed down. The approach to managing work was well suited to operations as well as projects, and the team focused on continuously improving themselves, whilst remaining flexible enough to work on whatever items of work were prioritized by the business.

Traditional project management stayed too. Jez continued to work for Sarah and they built a strategic Project Management Office which focused on supporting strategy definition, planning, and both agile and project delivery. Through what started as a reaction to stagnating sales, had developed new ways of working and was ready to face the future.


This scenario is not an uncommon one. Modern project managers are expected to bring a wide range of tools and techniques into organizations to help them deliver faster than ever before. Frequently project managers have to work across business silos to get work done, experiencing all manner of resistance and disillusionment along the way. Agile techniques are massively growing in popularity, due to their ability to handle complex problems that traditional methods tend to struggle with. Good project managers will know when to deploy agile techniques, and when to use traditional approaches. Excellent project managers will know how to mash them together to maximize delivery.

And the strategic PMO? Well, they are becoming part of the project success story in many organizations, helping deliver the right things faster, whether that be with project managers leading projects, program managers leading programs, change managers initiating change, agile teams blurring lines between operational and project work, or coaches working to help people and teams be the best that they can be.


  1. Alex Cretney

    This is absolutely fantastic! Loads of great information here in a practical scenario and you’ve folded in warhammer to boot! Story mapping is a new one for my repetoire!

    • John McIntyre

      Thanks Alex, glad you enjoyed it. Story mapping is a great technique for getting to very thin-slices of value. I hope you have fun with it.


Submit a Comment

Your email address will not be published. Required fields are marked *