Forty-seven project management processes exist under 10 knowledge areas. Poor communication causes one-third of all projects to fail. Businesses waste $97 million for every $1 billion invested in projects.
GetApp knows how overwhelming this is—especially for project managers of teams with fewer than 10 members. With so many methodologies to choose from, how can you find the best fit for your own team and avoid the problems above?
Below, we’ll share answers to common questions about how to choose the best methodology for project teams under 10. They should give you a head start on understanding which methodology is the best fit for you.
What’s the most common project management methodology for teams under 10?
When GetApp asked close to 200 project managers in the United States which methodologies they use, nearly half (43 percent) said they don’t use a methodology at all. Within that group, 47 percent of PMs on teams that don’t use a methodology said they have no plans to start using one.
2. Does my project team need to use a methodology?
Not using a project management methodology can be a good thing. Depending on your team’s needs, it might even be the best choice.
Gartner research (available for clients) advises leaders to learn which tools their teams use to collaborate ad hoc. Author Jeffrey Mann says that strict processes aren’t needed on teams in which “project management” is a synonym for “collaboration.”
In those cases, team leads should notice which tools colleagues use to do spontaneous work. Then, they should encourage their teams to finish less structured projects using these collaboration tools.
3. Which project teams would benefit the most from a methodology?
Teams delivering software projects.
One in 4 respondents of GetApp’s survey either worked in IT or technology/software. And while collaboration plays a key role in software projects, these teams need a more formal plan as well.
The software development process involves a series of steps, from conceiving and specifying to testing and bug fixing. And since software projects support specific products (aka the software itself), you’ll manage a constant series of projects throughout this software product’s life cycle.
4. What’s my biggest risk if I don’t implement a project management methodology?
Delivering projects late and/or over budget.
It’s true that if your project team is more focused on team collaboration, you might not need a methodology. But using one has a huge influence on the rest of your project team, and evidence shows that it’s a positive one.
Samuel Malachowsky, an author on project management and lecturer in the department of software engineering at the Rochester Institute of Technology, explains that methodologies affect everything from sales and quoting to budgets and schedules. These methods also help project team members track work, visualize progress, and prevent problems.
“So are teams more likely to deliver on time and under budget?” Malachowsky asks. “Yes—but more importantly, they are more likely to have more accurate budgets/schedules and the visibility to know where they measure against them.”
Without putting a process in place for all team members to follow, you run the risk of managing projects that run late or over budget. These constant challenges can impede the software product, which might serve as your small business’s backbone. And considering half of all small businesses fail before they turn five, every dollar counts.
5. What’s the best methodology for projects that need heavy testing?
The Six Sigma methodology aims to eliminate defects and waste by understanding customer concerns. Its key benefits include:
- Understanding how customer requirements change
- Improving quality and delivery
- Reducing waste and cost
- Developing strong products and processes
- Continuous improvement
- Enhancing your business’s competitive position
Six Sigma demands deep knowledge of statistics and engineering along with project management. That makes it ideal for project teams in industries such as finance, medicine, and the military.
In these cases, “you must have code freeze before a battery of testing goes on and a release pushed, assuming all the tests passed,” Alexis Wilke, CEO at Made to Order Software Corporation, explains. In most cases, this means the team starts on a new branch of the project to work on the next version while the testers verify the frozen code.
“If a bug is discovered, then a fix for that bug is worked on in the release branch,” Wilke adds. “No other code changes are made to that branch. This makes for a slower process, but the resulting code is likely much more secure and functional.”
6. What’s the best methodology for project teams composed of knowledge workers?
Scrum or Kanban.
Scrum and Kanban are two separate methodologies that fall under the Agile umbrella. In other words, Scrum and Kanban are not synonyms for “Agile” (which we’ll discuss in a separate section). Instead, Scrum and Kanban are two separate frameworks to implement the Agile methodology.
Scrum fixes time and cost to control requirements. Direct work between the project and customer success teams is essential to make Scrum succeed. As a result, Scrum is ideal for small teams under 10 that work on collaborative projects.
Scrum teams work within iterations called sprints that last no longer than one month. To track progress on these sprints, Scrum teams hold daily 15-minute standups to track progress on these sprints.
Kanban manages product creation with the goal to fulfill continuous delivery without overburdening the development team. Its key goals are to:
- Visualize your workflow for work that’s due today.
- Limit the amount of work in progress so teams don’t overcommit to an unsustainable amount of work at once.
- Enhance flow so that the backlog is prioritized and high-priority items are pulled out.
The Kanban method promotes continuous improvement by trying to optimize team workflows. As a result, it’s a good fit for project teams working on projects that roll up to ongoing products.
“For teams that are comprised of knowledge workers (think: software developers, scientists, sales, marketing, etc.), my default recommendation is Agile/Scrum or Agile/Kanban,” Shai Sandil, founder and CEO of Soft Solutions Consulting, says. “Both these methodologies are rooted in the idea that project requirements are always changing, and responding to these changes are vital to the success of the project.”
7. What’s the biggest barrier to researching methodologies?
Not having support from leadership.
Lack of executive sponsorship is one of the main reasons why projects fail. This makes sense when you consider that the sponsor’s role is to set the project’s vision and explain how it will enhance business goals. Without this leadership, it’s tough to know which methodology is the best fit for your team and the project at hand.
“One of the biggest barriers is not having support by leadership,” Sandil says. “Often, this manifests itself in a rather casual ‘let the team do whatever they want’ type attitude. While this is better than a hard ‘no,’ it’s also difficult when the team puts pressure on leadership to commit resourcing to the methodology.”
To avoid this challenge, own your role as the project lead by making a clear case for why you’ve chosen a methodology. Explain to leadership why your chosen methodology is the right fit for your team and how using it will scale the business.
8. What’s the most important factor in successfully implementing a methodology?
Making sure that everyone will follow it.
Research shows that during times of change, leaders are unclear about their expectations. They often express their desired changes in terms of tasks, not outcomes. Since many are creatures of habit who resist change, it’s not shocking that this leads to poor outcomes.
As the project leader, your job is to tell your team why you’ll have better results using your new methodology of choice. This is especially crucial if your project team has never used a methodology before. Focus on explaining why your old way of working isn’t enough and how your new methodology will bring better results.
“The key is for the team to wholly ‘buy in’ to the methodology,” says Shandil. “For example, if the team has three members, an overhead-heavy methodology will rarely work. Meanwhile, a team of 10 will not be able to get away with a methodology that focuses on face-to-face communication (purely because we don’t want to waste 10 people’s time for a discussion).”
9. Is it okay to start using one methodology and transition to another?
Yes—as long as your new method aligns with your project’s strategy.
Many project leads find a need to switch as their teams scale and customer requests grow. This is especially true if your team works on software projects.
“Early in the project, the Kanban methodology makes more sense,” Wilke explains. “This is because there should be no reason for a programmer to stop working on a feature when working on a new project. So one will work until that feature is complete and that part of the code is ready to be released.
“Once you have a functional product and constantly have customers hungry for new features, a Scrum methodology for the team on the forefront should be used,” Wilke says. “In this case, the manager is responsible for maintaining a list of new features and bugs and prioritizing those. When a new milestone is set up, the set of features and bugs with the highest priority gets worked on for that milestone.”
That said, Malachowsky doesn’t recommend switching in haste. Project team members are most likely to succeed if they’re using methodologies that are familiar to them. So, any decision about which methodology your project team should switch to should start by considering each team member’s background.
“Chances are greater that the team will succeed with the methodology they’ve previously used,” Malachowsky says. “This can be the team itself (if they’ve worked together before), the individual members (following organizational standards), or industry norms (if it’s a recently hired team). Though other considerations follow, this is the very first one.”
10. Can my project team use a methodology as more of a guide rather than following it by the book?
Yes— methodologies are frameworks with nuance, not prescriptive absolutes.
If you’ve ever run a race, you likely followed a training plan. But did you follow that training plan to a T? Probably not.
One of the reasons for the growth of Agile methodologies is that they account for nuance: The manifesto prioritizes people over processes. So, it’s not a bad thing to use your methodology as a guide for your team rather than a locked-in process.
On the contrary, small project teams will likely need to build change into their planning. Any methodology you choose should align with your project and organizational goals. Beyond that, you can adapt your methodology as needed.
“If a methodology is not working, drop it, try something else, or change it to fit,” Sandil says. “There is no such thing as a ‘by-the-book’ methodology; adapt to meet your unique needs. As a consultant, I really shouldn’t be saying that last sentence, but the truth is the truth.”
11. What exactly does ‘Agile’ mean?
It’s an umbrella term for several methodologies that help project teams respond to change
“Agile” isn’t one methodology. Rather, it’s a set of methodologies (including Scrum and Kanban) that help project teams address change.
Given this broad goal, project leaders can apply their Agile methodology of choice to a wide range of projects, from marketing to software development. You can consider an Agile methodology if your project:
- Relies on close collaboration between the development and business teams
- Must deliver ongoing business value
- Has flexible requirements
- Has self-organized teams, ideally of nine people or fewer
“If the project is complicated or complex and requires a regular interaction between the product owner and the team, then Scrum would be the best methodology,” Alan Zucker, founding principal of Project Management Essentials LLC, says.
“Scrum is best when we are building new applications or making significant enhancements to a legacy application where we want to deliver value incrementally and we want to have daily interaction between the development team and the business.
“If we are focusing on managing the flow of work on a project and eliminating waste, then Kanban would be the preferred methodology.”
12. Alright, we’ll give Scrum a try. What are the first steps we should take?
The first step with Scrum is to assign the roles of product owner and Scrum master to members of your team. (You can learn more about these roles here.)
To successfully implement Scrum, your product owner will set predetermined time frames for your team to complete tasks from within the project backlog. These predetermined time frames—aka “sprints”—can last up to one month, but typically go for two weeks.
“We are building a product and the requirements and the priorities change on a regular basis (weekly if not daily),” explains Nitin Verma, co-founder of Orgzit. “The work of our teams was highly interdependent, so it was really critical for every team member to know what the other teammates were working on and whether they needed to go out and finish something that their teammates were blocked on.”
To track progress during these sprints, Scrum teams hold a brief meeting each day called “The daily Scrum” or “daily stand-ups.” These meetings should give team members the chance to share high-level updates on their work in 15 minutes or less. The key to successful stand-ups is to strike the right balance between brevity and teamwork.
“We followed a very basic daily scrum method and simple tasks lists,” Verma says. “The setup basically required every team member to address 3 questions every single day:”
- What did you accomplish yesterday?
- Were you or are you blocked on anything?
- What are you going to work on today?”