13 Project Management Best Practices When Outsourcing Software Development 

If you think that is bad, wait until you learn about outsourced projects. Take, for example, Dun & Bradstreet’s Barometer of Global Outsourcing. It says that “20 to 25% of all outsourcing relationships fail within two years, and 50% fail within five”.

Yet, some companies achieve a much higher success rate. I’ve been working as a professional Project Manager at MindK for the past 7 years. In that period we’ve, we delivered 96% of projects on time and within budget, with an average relationship of 5 years.

Want to know the secret? Here are some of the project management best practices I use daily to succeed on my projects. Please, enjoy.

Table of content:

• #1 Build trusting relationships with your stakeholders
• #2 Organize good teamwork
• #3 Communicate, communicate, communicate
• #4 Define clear project deliverables and milestones
• #5 Approve the project goals and scope
• #6 Ensure everyone has clear roles and responsibilities
• #7 Be realistic about your schedules
• #8 Identify risks early on and create mitigation plans
• #9 Report your progress and keep your documents in order
• #10 Watch out for scope creep
• #11 Prevent burnout in your team
• #12 Encourage feedback at all stages
• #13 Get customer acceptance at the end of the project

13 project management best practices of successful teams

#1 Build trusting relationships with your stakeholders 

On most projects I have 2 primary stakeholders – the client and the team. 

Transparency and trust are essential to establishing great relationships with both. This way, you can become a true Agile team, where there are no Big Bosses and little servants. I use several project management strategies and techniques to establish trust and transparency:

Tell the truth, even when you messed up. Clients shouldn’t learn about an issue when they start losing money. So reveal any problems upfront! And don’t forget to offer an adequate solution to show you care about their business.

Send detailed invoices. Our engineers log the time they spend on specific tasks. A client then receives a detailed report that compares the estimated and real duration of tasks. Such reports help clients track the project budget in real-time.

Small talk makes a great difference. Sharing personal information helps in building trust and lasting relationships. Another thing that helps is to remember those bits of info for later use. So, if I hear that our client’s son has a birthday next Sunday, I send him a nice b-day card.

Show your team as often as possible to the stakeholders. I like to invite the clients to our daily meetings every now and then and have live demos with the entire team. This helps build relationships with the client and understand that their project is the work of a team and not a single manager.

Build a sense of ownership in your team. I always refer to the client’s product as “our product” so that my team starts feeling like a part of the client’s business. Take, for example, one of the projects I currently manage – a cloud-based sustainability reporting tool chosen by Forbes Global 2000 companies. After more than 10 years of cooperation, the client now considers our engineers as their own employees. This is the best feedback you can get as a Project Manager.

CemaSYS – a SaaS environmental reporting solution developed by MindK [read the case study]

#2 Organize good teamwork 

Both processes and communication are essential to teamwork. 

Scrum is a great framework that can help you structure processes in Agile teams. It involves splitting larger chunks of work into more manageable iterations. Each of these so-called Sprints usually has the same duration (between 1 and 4 weeks) and a single goal. 

Before the start of each iteration, the team will gather with a client representative (Product Owner) to plan the work for the next Sprint. They will define the team’s priorities, estimate the highest-priority features, and move them to the Sprint backlog (it represents the amount of work that needs to be done by the end of the iteration). In the next few weeks, the team will design, program, and test a few features that can be released to provide value to users.

In addition to Sprint planning sessions, three other Agile rituals can help you deliver value at a steady cadence:

• Daily standups

During these 5-minute meetings, the team discusses the task done the day before, the work for today, and any issues that block the project. A pro tip I came to appreciate is to invite the client representatives to our daily standups. 

• Sprint reviews 

At the end of each iteration, the team gathers to discuss the work they’ve done on the project. This is the perfect opportunity to invite key stakeholders for a live demo of the completed features and ask them to provide feedback. I like to engage the entire team in the process as everyone can make a valuable contribution. This also helps establish relationships between the team and clients.

• Sprint retrospective

This is another meeting where we review the previous Sprint. The focus is on the processes instead of the product, though. This is an opportunity to discuss your mishaps, resolve conflicts, and find opportunities for improvement. 

You should, however, avoid blaming individuals. A sense of psychological safety is the main characteristic of high-performing teams, according to a massive study by Google. So strive to have a culture where it’s OK to fail and be open about your mistakes. It is also why I don’t recommend inviting stakeholders to retrospectives.

#3 Communicate, communicate, communicate 

On-point communication is essential for project management. Stakeholders are all busy people, so it’s a good idea to create a communication plan that satisfies all parties. 

I usually take some time to discuss the availability of each stakeholder before the start of a project. 

When implementing project management best practices, have weekly calls with the client, send follow-up status reports, and invite them to the Sprint reviews. For some clients that is more than enough. Others will prefer more of a hands-on approach to development. So it’s always a good idea to approve your communication plan with stakeholders.

Team communication is just as important as your processes. From my experience, critical issues on the project often result from simple misunderstandings. You can sometimes hear heated arguments when both sides are basically advocating for the same thing using different words. I try to diffuse such situations as soon as possible by helping them to find common ground.

Team building, both online and offline, is one successful project management practice you simply can’t ignore. We’ve all seen casual Friday parties, paintball sessions, or beach volleyball games. But you can also make your Agile rituals less stiff. For example, start your retrospectives with a little game – try to guess the name of a movie from a chat emoji or choose between two extremes in a game of “Would you rather”. And then end the meeting on a positive note to set the mood for the day.

Summer team building at MindK

#4 Define clear project deliverables and milestones

A deliverable is any results from a project – working software, servers, or related documentation. Different stakeholders will often have wildly different expectations about the project, so you need to first determine their requirements. This is a gradual process on Agile projects.

It begins at the presales phase. We usually have professional Business Analysts and Tech Leads talk with the client about their high-level business needs. This is usually enough to define large pieces of functionality called epics and estimate the effort to complete them.

When you have the initial requirements, it’s time to document the project goals, deliverables, and milestones. A Work Breakdown Structure (WBS) can help you split larger epics into individual features for easier estimation and planning. It also helps identify any dependencies between tasks to determine the correct sequence of actions for your project.

But what should you do if the customer requirements are just too vague to get a good WBS? 

In these cases, I like to invite key stakeholders to a 2-day requirements gathering workshop to answer the following questions:

• Who are your intended users? Create a user persona for each category of people using your app. 
• What is the goal of your project? What are its benefits for the business and its customers?

• How can you measure project success? Define your S.M.A.R.T. KPIs (Specific, Measurable, Attainable, Relevant, and Timed). 
• What are the most important features you should include in the 1.0 v. of the product? 

Running the entire workshop as a fun game keeps everyone engaged. The key is to document everyone’s unique perspectives on the project goals and requirements. For more information, check our article on requirements gathering process.

Each deliverable should have a clear definition of done (DoD) – specific criteria that make it acceptable for the team, stakeholders, or customers. 

Placing deliverables on a schedule produces milestones. Some project managers set up unrealistic milestones to please the higher-ups and clients. This often leads to exhausted developers and disappointed customers. Don’t be afraid to stand up to stakeholders to protect the team’s time. 

OnePager milestones tracker. Source: OnePager

#5 Approve the project goals and scope

The goals of the project, its deliverables, and milestones, represent the project scope. Good project scope should answer the following questions:

• What are the project objectives? 
• What are its functional and non-functional requirements?
• What are its deliverables?
• What are the project constraints (quality, budgets, schedule, risks).
• What are your assumptions about the project?
• What should stay out of the project scope?
• What should be the formal process for introducing any changes to the project scope?

It’s essential to get formal approval for the scope from stakeholders to ensure unity on the project. 

#6 Ensure everyone has clear roles and responsibilities

Every project needs resources – money, equipment, and people. Having a work breakdown structure allows you to determine the resources necessary for each task. Many people on your team have to juggle multiple projects, so keep that in mind when planning your activities.

It’s also a good idea to become crystal clear about individual duties to the project to avoid confusion. If you have lots of stakeholders, there’s nothing better out there than the R.A.C.I. project responsibility matrix. For each task on your project, define the people who are:

• Responsible – will do the task in person. For example, a developer is responsible for implementing the log-in feature.  
• Accountable – will make decisions about the task. For instance, a Tech Lead may be accountable for implementing the login feature.
• Consulted – will provide inputs when making a decision about the task. You might want to consult with a Product Owner before implementing the login feature. 
• Informed – will get updates regarding the task. You might want to inform users about any changes to the login process.

Once you have the RACI matrix, share it with other stakeholders, ask for feedback, and get their approval. 

#7 Be realistic about your schedules

You’ve broken the project into tasks, identified dependencies, and taken care of resource availability. Now it’s time to create a solid project plan. Instead of using multi-year plans, Agile teams usually have product roadmaps that set the general direction for the project. 

Remember, your schedules need to be both realistic and achievable. After all, each team can only accomplish a certain amount of work within a time-limited Sprint (represented in man-hours or story points). Before the start of each Sprint, the team estimates the highest-priority tasks on the backlog. This stops when they reach a certain amount of story points a team can realistically complete within one Sprint. 

Your first estimation will always include a ton of assumptions. Good project managers always compare the team’s real progress against the previous estimates. Tools like burndown charts allow you to track productivity in real-time and make your future estimates more realistic. You can then adjust your total number of story points per Sprint or look into the reasons why the team’s productivity dropped.

Burndown charts can help you track team performance in real-time. Source: visual-paradigm.com

#8 Identify risks early on and create mitigation plans

The first rule of project management is that you don’t talk about project management. The second rule is that anything can go wrong at any time. So one of the PM best practices is to create a list of risks that might happen during the project. For each risk, define:

• How likely are they to happen?
• How badly would it impact the project?
• What can you do to avoid or mitigate this risk?
• Who will be responsible for each specific risk?

Remember, risks can also be positive. So keep track of project opportunities along with your risks and remember to update the list from time to time. 

#9 Report your progress and keep your documents in order

Keeping stakeholders in the loop is one of the most important recommendations for successful project management. For this exact reason, you should also update the key project management documents from time to time:

• Project log with major project decisions.
• Meeting notes.
• Project budget.
• Risk management plan.
• Project responsibilities matrix (RACI).
• Change request logs.
• Project backlog.
• Project schedule.
• Burndown charts.
• Team retrospective journals.

Just don’t overdo the documentation! Remember, Agile teams value working software and collaboration over mountains of paperwork.

#10 Watch out for scope creep

This uncontrolled growth in ambitions happens in over 50% of projects. It happens when stakeholders keep altering project goals, adding new requirements, and increasing the amount of work that needs to be done by the team. For this reason, scope creep is one of the main causes of project failure. Here’s how to avoid it:

• Set measurable project goals during the initiation phase and get a written agreement from stakeholders. Poor definition of the project scope is the primary cause of scope creep. 
• Involve stakeholders as much as possible. Discuss the scope and report regularly. Set clear priorities together and explain to stakeholders why certain changes are better left for future Sprints. Be clear about the business consequences of every new change. Explain that adding project goals beyond its original objectives often leads to diminishing returns.
• Learn to say NO. Different software development methodologies have different approaches to managing changing requirements. In Agile, stakeholders are free to add new requests at any time. Yet, the scope is fixed for the current Sprint. So add any new changes to the product backlog. For Waterfall projects, I recommend formalizing any new requirements as change requests (CR) and using our 7-step assessment process for each CR.
• Add scope creep to your risk plan. Add scheduling and resource buffers to account for such a possibility. 

MindK change request form

#11 Prevent burnout in your team

Humans can’t work 24/7. Overload them with too many tasks and watch productivity drop like a sack of potatoes. Do this on a regular basis and risk losing your best engineers to burnout.

Many project management tools like Asana have features that can help you create a manageable workload for your team. They allow you to limit the number of tasks in progress for each (which is one of the best project management practices in the Kanban framework). 

I also have one-on-one meetings with my teammates every 3 months. This is the perfect opportunity to gauge their work satisfaction and find opportunities for improvement. I also encourage my mates to share their problems as early as possible. If I see that one of my engineers is overstressed with a complex task, I give them an easier task to recoup their mental resources. Offer your team both material and non-material rewards. Salary bonuses, creative presents, or team-building events may all contribute to increased morale. 

Painting Christmas balls at a MindK team building event

#12 Encourage feedback at all stages

Continuous feedback is a foundation of most effective project management practices. Agile rituals like daily stand-ups are a great way to discuss any pressing issues on the project. Sprint reviews allow you to get instant feedback from clients about the new features. And Sprint retrospectives offer an opportunity for the team to share complaints and discuss any challenges in a blameless environment.

It’s important to capture feedback from everyone on the team, even if their contribution seems small. It’s your job as a Project Manager to help people open up, maintain civility, and resolve any conflicts in a productive manner. 

#13 Get customer acceptance at the end of the project

Here’s a question: what are the signs of successful project management? 

• You reached the project goals.
• You’ve completed it within the initial budget and schedule.
• The product has an adequate quality.
• The result satisfies the customer requirements.

The last point is arguably the most important. That’s why it’s important to get formal approval from stakeholders. At this stage, you can employ User Acceptance Testing (UAT). It basically means giving the product into the customer’s hands to understand whether it meets their expectations. 

As a result, you can determine your next steps – release the product “as is”, improve in the next iterations, pivot following feedback, or scrap the project entirely. 

The last option is far less common with Agile methodologies as they reduce the risk of failure by up to 2.6x times. You also shouldn’t be afraid to pivot over the course of the project.

One of the projects I managed was a cloud-based recruiting solution for a Californian startup. As the first prospects started using the product, we learned that it couldn’t satisfy their needs in its current form. Our team used this insight to redesign the product and succeed with its second version. The same thing happened to Instagram, Twitter, g, and many of the Lean Startup followers  

Bridge – a custom SaaS solution we made for the recruitment industry [explore the case study]

Conclusion

Managing projects is hard. Use these project management best practices to drastically improve your chances of success. Standish Group notes that the number of failed projects drops significantly when companies adopt Agile approaches. 

From my experience, our processes have improved radically since MindK embraced Agile as one of the pillars of our company. Since then, we’ve delivered over a hundred complex projects on time and within budget. 

We’re all now swimming in uncharted waters. Succeeding in uncertain times requires more than technical and project management expertise. You need to understand how to bring all the elements together to save money in the long run and provide a competitive advantage for your business. And this is exactly what MindK does for its clients. So if you have a project in mind, just drop us a message to get a free consultation with our experts.