As an experienced Scrum Master with PSM certification and an Agile Coach, I facilitate teams’ progress toward common goals and focus on improving dynamics and performance. Throughout the years of my professional work, I have been responsible for supporting and enforcing the Scrum process and other rules that the team has agreed on.

Agnieszka Pawlicka

Grzegorz supports smart technically-minded people as a business consultant and COO.

Grzegorz Rduch

My diverse educational background allows me to approach software development problems from different sides and angles. I have bachelor degrees in Sociology and IT in Business. I am an agile Team Leader and Project Manager. Sport and Combat training allowed me to learn that success comes with hard work. Along came the self-improvement, loyalty, discipline and self-control.

**ABOUT MY TEAM** “...there is no **I** in **Team**”

My Team has an in-depth and long term experience (**4 years** on average) and currently consists of **9 members**. We specialize in **Ruby on Rails**, **React.js**, **React Native** and **Node.js**. We work from **one** **office** which guarantees close and **successful** **cooperation**. We use the following communication tools: Slack, Pivotal Tracker, Trello, Jira and Google Hangouts.

***"With few exceptions the best players are the hardest workers"***

I love coding and I **enjoy** **solving** **various** **business** **problems** with my programming skills.

I am a Head of Production who is passionate about crafting state-of-the-art functional software solutions. In the over 12 years of my professional career, I gained experience in building various types of platforms, which now allows me to mentor my colleagues and share my team-building and technology insights in blog publications.

Ireneusz Skrobiś

\[TOC\]

Imagine that you’ve got your next project in mind, you’ve got a timeline, budget and you’re thinking about getting started. The question is how do you make sure that you’re on the same page as your team and your clients before this happens?

Running a top tier kickoff meeting, of course - and we’re here to help with the following:

* Finding out what a kickoff meeting actually is, and learning how to run it properly.
* 10 top tips for your kickoff meeting.
* Planning an agenda.
* The best questions to ask during your kickoff meeting.
* What to do after the kickoff meeting.

Here at Selleo, we can help you with all of the above in a number of ways. But, before you get planning your amazing kickoff meeting, make sure you read on to find out everything you’ll need to know about it!

## What is a kickoff meeting and why is it important to run it properly?

A project kickoff meeting is a fundamental part of the project initiation. It’s either an internal (within your team) or external (between the team and the client) meeting that covers a number of areas, each of which we will discuss later on in this article.

Firstly, let’s take a look at why a successful project kickoff meeting can really enhance the overall success of your project.

#### What is the purpose of a kickoff meeting?

Your kickoff meeting will be a hugely important part of the project as it has the following benefits for you and your work. The meeting should:

* introduce the team to potential clients, which helps with team members to **client chemistry** and **mutual understanding** of the project. You could also introduce any project stakeholder at this stage;
* define a **project timeline** so that people know what needs to be done at exactly what time;
* be ornamental in setting the **tone** of the project. This will ensure that everybody is on the same page regarding the functions, aesthetics and any other part of the project.

Essentially, the overall goal of a kickoff meeting is to make sure that all those involved are confident in their mutual understanding of the project by **setting common goals**, establishing expectations and **gathering requirements**. To get that point, we’ll need to understand the kinds of conversation that go on in a project kickoff meeting.

<Baner name={scrum-master} />

You can also consider introducing an **Event Storming session**, which is really helpful during the first phase of software development. It enables to achieve a comprehensive and common understanding of the processes which should be transformed from the idea and vision into working software. Read more on Event Storming in my previous articles [Event Storming: How It Will Improve Your Business Processes?](https://selleo.com/blog/event-storming-how-it-will-improve-your-business-processes-) and [How To Run Your First Event Storming Session](https://selleo.com/blog/how-to-run-your-first-event-storming-session).

#### What is discussed in a project kickoff meeting?

![Img](https://a.storyblok.com/f/86602/720x367/4dde0f941d/what-is-discussed-in-a-project-kickoff-meeting.jpg)

Any good kickoff meeting agenda will discuss the following points at the least:

* Who the project team is, who to talk to about which things, and who the clients are.
* What the client, or project manager is looking for. Define a statement of work.
* The scope of the project - how much work is actually going to go into this project, and how time-consuming it could be.
* Thorough project planning.
* Motivational points. Get everybody excited about the work that they are about to embark on.
* The business case for the project.

We’ll show you how to put together a **kickoff meeting agenda** in more detail later on. But let’s take a look at agile project kickoffs first.

<ReadMore> Read also: [Agile Software Development Process – Everything You Need to Know](https://selleo.com/blog/agile-software-development-process-everything-you-need-to-know) </ReadMore>

#### What about agile project kickoffs?

Any of us who have worked on an agile project before, using **Scrum methodologies** or others, will understand that things work a bit differently from a regular project. As such, your project kickoff meeting is likely to look a little different, too.

While the overall purpose of the meeting is going to be the same, the project management methodology will be different, and so will some of the goals of the meeting. These include:

* Detail which tools will be used to communicate between team members and clients.
* Decide on sprint length, so everybody knows exactly when each project phase begins and ends.
* Find out from your team members how they like to work in terms of workflow. Understanding their strengths and weaknesses will reap benefits in terms of time management and overall project quality.

So, now we’ve begun to build a picture of what kickoff meetings should look like and how they can be the foundations for good projects, it’s time to look at some top tips for a high-quality kickoff meeting.

## 10 tips for a great kickoff meeting

![Img](https://a.storyblok.com/f/86602/720x702/0cda5b7741/10-tips.jpg)

Advice on running your project kickoff meeting could prove invaluable to the success of your project, so make sure you consider what we think are the 10 best tips for an amazing kickoff meeting:

 1. **Hold the meeting at your office, if possible:** everyone knows about the home advantage in football, but it works for offices, too! ‘Playing at home’ will help to make your team feel more comfortable and relaxed, thus boosting engagement and energy. Note: Due to the pandemic, you can also run your kickoff meeting remotely taking into consideration our tips on organising remote agile work I was writing about in [How To Sustain Performance While Working Remotely? 5 Helpful Agile Practices](https://selleo.com/blog/how-to-sustain-performance-while-working-remotely-5-helpful-agile-practices).
 2. **Plan a clear agenda:** you should want your meeting to be concise, so that everyone maintains concentration, but thorough so that you get to say everything that you need to say.
 3. **Host an internal kickoff meeting separate from any client-facing ones:** before you even think about introducing your team to clients, make sure that you have met with them privately beforehand. They’ll need to be on the same page as you.
 4. **Use DACI (Driver, Approver, Contributors, Inform):** this framework is a great way to assign team members their roles. You’re likely to have several people in each of these roles, so make sure you play to your team members’ strengths.
 5. **Manage expectations right off the bat:** make sure everyone knows what you are looking for from them and from the project overall. You should be the person who translates your clients’ needs into a workload for the team.
 6. **Divide the plan into the following three phases:** before the meeting, during the meeting and after the meeting. We’ll explain what should happen at each of these points during the next stage of this article.
 7. **Understand your client:** what could be more important? Use the opportunity of the introduction of your team to your client to finalise what your client is looking for and to understand their approach to taking risk so that you know what your limits are.
 8. **Represent yourself and your team well:** dress smart, make your space presentable and well-stocked, be energetic and maintain a positive attitude. These things will really help to build a strong relationship with your client.
 9. **Make sure everyone is on the same page about the direction of the project:** if anyone has any disagreements about the project, the kickoff meeting is a perfect opportunity for them to voice it before it causes problems later down the line.
10. **Prepare, prepare, prepare:** make sure that you’ve read into the background of your client, who will be attending from their team, their competitors and more so that you can tailor your own approach to get the best out of them.

<ReadMore> Read also: [7 Agile Best Practices You Should Know](https://selleo.com/blog/7-agile-best-practices-you-should-know) </ReadMore>

## Before the kickoff meeting: agenda

Now, we’re moving closer and closer to the initiation of your kickoff meeting. This is an exciting time, as you are about to embark on the first and one of the most crucial stages of your project as a whole.

But what do we need to do before the kickoff meeting even begins? We’ve put together a checklist for you to consider as you approach those crucial final moments before things kick off.

* **Assign a note taker:** this one might seem simple but it is often overlooked which can lead to disastrous consequences. A lot will be being said during your kickoff meeting, and you’re not going to be able to remember all of it, so someone needs to be able to write down the key points.
* **Decide who’s coming:** don’t invite anyone who isn’t fully necessary. You don’t want to waste their time and overcrowd the room without reason. On the flip side, it’s even more important not to miss anyone important out.
* **Set the agenda:** you’re in control, and everyone in that meeting is going to be looking to you to find out what needs to be discussed. Of course, you don’t want to be talking too much, but you’ll need to direct people to particular points throughout.
* **Figure out how much time is needed:** now that you know everything that’s going to happen during your kickoff meeting, you’ll need to decide how long the length is going to be so that attendees can schedule it. Make sure to leave time for breaks etc.

![Img](https://a.storyblok.com/f/86602/674x905/82b8224ddb/zrzut-ekranu-2021-06-29-o-09-06-25.png)

From [LucidChart](https://www.lucidchart.com/blog/kickoff-meeting-agenda)

<Baner name={agile-team} />

It would also be a good idea to put together a project planning timeline before you start the meeting. Perhaps print it out, or show it on a screen, so that everybody working on the project can start to appreciate the timescale of the project.

The project timescale should include items such as project initiation, meeting with the project stakeholder, defining the goals of the project, planning, development, testing, launch day etc.

## Questions to ask during your kickoff meeting

Alongside making sure that all the members of your project team are up to speed with the scope of the project, you’re going to want to find out a lot of information from them, and from your clients.![Img](https://a.storyblok.com/f/86602/720x367/381c2d7dfd/questions-to-ask-during-your-kickoff-meeting.jpg)

For this reason, asking the right questions is key, both of yourself and of other participants to the kickoff meeting. We recommend asking the vast majority of the following questions, as well as more specific ones to your project.

### Product

* Are project objectives defined?
* Is the scope of the project defined?
* Did you make a list of deliverables?
* Did you prepare a structure diagram of your future system that contains a mapping of all the apps/services that create the system?
* Did you specify who is the owner of each domain?
* Did you build a glossary of terms and definitions specific to your project?
* Did you think of any potential product risks?
* Did you decide what technology stack will be used?
* Did you choose the tools that will support the development process?

### Process

* Did both sides choose a person-of-contact on their side?
* Did you determine a form of communicating the progress?
* Is Scrum the chosen methodology? Do all the stakeholders understand the assumptions of Scrum?
* Did you determine what is the workflow of delivered features?
* Are the time frames established? Is the length of Sprints defined?
* Did you prepare a roadmap of the whole project?
* Did you secure enough time for automated test coverage on the critical parts of the system?
* Did you define which stakeholders will take part in which meetings?
* Is there an external development team? Did you plan pair programming between the teams?
* Does everybody know their next step to do?
* Did everybody report their needs in terms of access? Does everyone have a required setup to proceed with the development process?
* Did you think of any potential project risks?
* Is everyone aware of their responsibilities within the project?
* Are the work hours defined and accepted by both sides?

### Other

* Do you have a set budget in mind?
* Did everyone have a chance to ask potential questions?
* Are there any hot-spots that need to be answered? Is there a list of those hot-spots?

It’s important to differentiate the product and the process as not only are you likely to have different members of the team working more heavily in one area or the other, but it will also make documenting the meeting and therefore planning the rest of the project easier.

So, the meeting is done! What’s next to do?

<ReadMore> Read also: [Why Do You Need A Scrum Master? A Report From The Battlefield](https://selleo.com/blog/why-do-you-need-a-scrum-master) </ReadMore>

## To-do’s after your kickoff meeting

You’ve made it to the end of your kickoff meeting and you’re happy that everybody is on the same page and ready to get stuck into the project. Congratulations! So, how do we wrap up? There are three important steps to finishing up any kickoff meeting.

Check them out.

#### Close the meeting

Now that you’ve worked your way through the questions checklist and covered every other part of your kickoff meeting, it’s time to close it. Encourage your team to **ask any questions** or to voice any concerns that they may have at this stage.

Make sure that everybody involved has your, and each other’s, contact information so that you can reach out to one another moving forwards, and define any communication or collaboration software that will be used.

It would also be a nice touch to send out a summary of the meeting to everyone who attended, and especially those who could not make it to try to bring them up to speed as well.

#### Document it

![Img](https://a.storyblok.com/f/86602/720x367/b066179ecc/document-it.jpg)

Now, it’s time to partner with the note taker. You don’t need a full, **word-for-word transcript** of the kickoff meeting but it is a good idea to have the majority of the important points written down so that you know how to put a project plan together.

There are plenty of tools available online that can help with this. They can assist with defining and managing your project as well as keeping project stakeholders up to date.

You’ll also be able to share these documents with your team, and if you wish, to allow them to make edits and updates as they move through the project.

#### After the kickoff meeting

Now that you’ve concluded your kickoff meeting and **[documented everything you need](/blog/how-good-kick-off-documentation-can-accelerate-your-project)**, it’s time to get started! But what’s the best way to do that?

One essential tool is a collaborative work management tool. Here, you can share all of the work, updates and messages between your team, project stakeholders and clients with the minimum of effort and the maximum of efficiency.

## Summary

Congratulations on holding your awesome kickoff meeting. You’ve put yourself on the right track to working through a project that everyone involved is going to be happy with, thanks to great communication and planning.

To continue that communication and planning throughout the project and beyond is the next essential step, and [Selleo can help](https://selleo.com/software-development-team).

We’ve put together project management tools for a whole host of clients, and we’re confident in our ability to help you bring out the maximum amount of efficiency from your team with these tools at your disposal.

Holding an awesome kickoff meeting is a great start but the project has only just begun now. Make sure that you carry that momentum and work with the right people moving forwards.

[Reach out](https://selleo.com/contact) to Selleo for a consultation today and see what we can do to help you deliver your best work.

You’ve got your next project and you’re thinking about getting started. The question is how do you make sure that you’re on the same page as your team and your clients before this happens?

How To Run A Winning Kickoff Meeting

Introducing a new developer to an existing project might be a long and unproductive process. Because of that, it is wise to approach this challenge with some kind of plan. In this article, I will focus on the four key ingredients of adding a new team member:

* the new developer
* the team
* the client
* the project

Please note that I am writing this article from the perspective of a team leader that works in a software development house. The dynamics of my position brings a lot of opportunities to be introduced to a new project created by external companies and to introduce new developers to the already maintainable applications.

### New developer

Depending from the experience of the new team member, starting to work on a new project might be both stressful and challenging.

To release tension you can simply** ensure that everything will be alright.** It might sound silly but a few words of encouragement cannot hurt anyone and shows that you actually care.

You should spend some time and **explain in detail the role **a new team member is going to fulfill in your team. It is crucial to make sure that you are on the same page when it comes to your expectations.

If a person is not experienced and the project is gigantic you can be honest and say straight away that you don’t expect much at the beginning. You can agree on some ‘special treatment’ period when the noobie can learn the platform without resolving any problematic features.

When it comes to creating your application more approachable you can **guide through how the application works** and show the most interesting parts of the codebase. But please make sure that new developer understands business goals and contexts behind the application as well as how it works. And whenever possible, **do a pair programming**. In my opinion, pair programming is a marvelous way of helping others find themselves in a new application.

You can also focus on the tasks you assign to the new developer. A small task can be a great way to start, but as soon as possible, you can give him something bigger and more complex. **Finishing a hard task on a new system brings a lot of confidence and builds the feeling of ownership.**

### The Team

Not only the new developer needs attention, your team also demands it. Bringing someone new to the team might raise a lot of questions. Why do we need him/her? Is something wrong? Is client not happy with our performance? Is a substitution planned? Because of that, it is good to have a team meeting **before** we actually add someone new. During that meeting, you can explain the reasoning and answer all the burning questions that your team may have.

Remember that you can always ask your team members for help in introducing the noobie to the project. I highly encourage to **schedule a pair programming session** with each team member. It is a fantastic way to build connections and share the knowledge about the practices you follow on this particular project.

### The Client

There is a great chance that the client (owner of the application) might have an impression that more people equals more tasks done. While it is true after some time, **at the beginning the productivity of your team will not change**. In some cases, it might actually drop a little because of the overhead a new person adds to the project. Someone has to invest time in that person and because of that, the overall productivity might be lower. **Make sure that the client knows and understands that.**

### The Project

I have seen a lot of projects throughout the 11 years of my career. Not all of them were easy to install and setup. To make sure that it is not the case on your project be sure that your** documentation is up to date **(and easy to follow). You should also invest some time and prepare** seeds that actually work **(writing specs for seeds is really helpful to make that happen).

**The most essential thing **that helps to introduce a new developer to the project is a **fast and reliable test suite**. Both unit and integration test should ideally cover each feature in your application. Thanks to that, you have a friendly environment to add/modify functionalities that will prevent your new developer from breaking something on production because of the lack of familiarity with the application.

The other things that are worth mentioning are **code reviews by a more experienced developer and QA** that a feature does what it was supposed to do.

### Summary

There is a lot of things that can be done to speed up adding a new member to the existing project. Some of them are trivial and some of them require a lot of goodwill and some sacrifice. From my perspective, it is worth to invest this effort because it builds foundations to create a happy and cooperative team.

Introducing a new developer to an existing project might be a long and unproductive process. Because of that, it is wise to approach this challenge with some kind of plan.

How To Introduce A New Developer To A Project

### “How do you overcome communication challenges?”

During early talks with a prospect, I was asked how we overcome communication challenges. I immediately thought about the Communications & Reporting Matrix we developed a few years ago and have attempted to refine ever since (see the figure below). It contains quite a lot of detail, yet it still does not tell the whole truth.

**Process / Communications and Reporting Matrix**

The matrix is basically a grid which captures the communication patterns between the Product Owner – on the client’s side – and the Team Lead / Development Team – on[ Selleo](https://www.selleo.com/)’s side. A kind of guide with *who*, *what* and *when*. Each time we found something that worked well with a client, we modified the grid, hoping to eventually arrive at a productive framework. We even included the matrix in the Contracts/SOWs signed with our clients. Somewhat surprisingly, after some time we noticed that:

\* in practice, we never fully applied the matrix as agreed with the client,

\* the actual communication practices differed, often widely, both across the teams and within a specific team for different clients served, although we diverted from the template and used varied communication practices, things very often worked well.

Though we still use the matrix, we treat it with an ample dose of scepticism when approached by a new client. This scepticism it does deserve.

**The major differentiator behind the practices seems to be the PO’s communication style**. Some POs favour written and asynchronous communication, e.g. e-mails and tickets, in the project management tool. We have, for example, served a client who first talked to us only when he came to visit us after months of collaboration. We talk to each other a lot when we are physically collocated, yet teleconferences are virtually absent from our daily interactions. By contrast, other POs are much more comfortable with spoken and synchronous communication. They prefer to teleconference / talk on the phone and sometimes seem to treat e-mail or the ticketing system as a last resort. One of our clients operating at this extreme,even had their corporate VOIP phone installed at our premises to be able to reach us in the way he found most convenient.

### **How to arrive at an effective communication pattern?**

If you are a Product Owner outsourcing software development – know thyself. **Understand your communication style and personal preferences in this respect and frankly tell the team about them upfront**. If you are developers delivering the services – listen (or read!) carefully from the very beginning. Having found out more about the specific client, tailor the process to fit their style and preferences. By no means adhere rigidly to what you believe works, even if it worked very well in the past.

If you have a predefined process and insist on compliance with it, your approach will appeal to some POs and alienate others. So it can pay dividends to have a process framework but remain flexible with it. If, for examples, you are working with a very busy entrepreneur, who is constantly pressed for time, develop executable tech specs yourself, have them approved by the client and try not to bother them during development; if the client has no time to accept deliverables during a teleconference, record video presentations for the client to review when it is convenient for them. By contrast, if the Product Owner likes to interact verbally, use regular teleconferencing; you can develop their software against higher-level tech specs as the client is available to clarify things along the way.

One might say the vendor’s Team Lead’s style and preferences also play a role. If only because, for instance, the Team Lead copes better writing rather than speaking the client’s language. They in fact often do play a role. They should not though. A good service provider and their people should fit in with the client served rather than the other way round, at least when they are serious about the quality of service they deliver and the customer experience they attempt to ensure.

### **Conclusion**

**There is no one universal way which will work for all the Product Owners and their teams**. An effective way to communicate needs to be collaboratively discovered by the specific people to work on the project. You may have a blueprint from which to start and which to tailor to suit the preferences of those you deliver your service to. The template may actually capture some of the good practices as well as strive to eliminate the [unproductive ones](https://www.softwaredevelopmentoutsourcing.eu/outsourced-software-development-insights-from-agile-by-example-2011-2/). Still, remember it is just a blueprint – a place from where to start rather than to arrive at. People differ and – if only because of that – there are many ways of arriving at a good solution. And, after all, communication is just a means to an end and not an end in itself, at least in the pragmatic environment of software development.

There is no one universal way which will work for all the Product Owners and their teams. An effective way to communicate needs to be collaboratively discovered by the specific people to work on the project.

The Product Owners Communication Style Process Adjustments

### **Why scope is crucial**

Assuming you want to make profits rather than products, scope is the main driver of your economic results. It ultimately determines the value you will deliver to your customers and, consequently, the **revenue** you will be able to generate from your product or software-enabled business venture. On the other hand, it will drive **costs** which will feed into the bottom line, more specifically, the expense of product development as well as the cost of support and maintenance. Since scope impacts your project schedule, do not overlook the cost of delay, i.e. the revenue you will lose as a result of deferring the launch of you product. Get it to the market too late, and you may discover your target customers are already locked into competitors’ solutions. Though the cost of delay may be hard to see, it may be much more important than the tangible costs you experience when parting with cash.

Failure to manage scope with the economic implications in mind, often leads to:

* developing products with no market fit – the worst scenario
* delays and lost revenue
* budget overruns
* high maintenance cost
* motivation melt-down  
  Conversely, manage you project scope well and you are much more likely to develop a profitable product – a product which sells well enough to provide ample excess of revenue over the costs incurred. Some say it is easier said than done. They see the point but lack the determination to do it. Others consciously, genuinely and persistently try to do it well and – with luck – they sometimes succeed.

### **Project type & initial scope definition**

Software development projects – outsourced or not – vary in type and size, which determines how well scope can and should be defined upfront. On one hand, you may need to port an existing well-documented application, in which case what is to be delivered is relatively easy to define and unlikely to change. At the other extreme, you may want to create a new application with high market risk, in which case your initial scope is often a guess – a collection of assumptions which will be tested with potential customers and/or users. Initial requirements are incomplete and very likely to change. In between the two extremes there are a number of other project types which vary in terms of how well scope can be captured upfront.

### **Project type impact on scope, process and team management**

Since the type and size of the software project you intend to outsource determines how well you can define scope, it will have an impact on:

* the way scope will be managed
* the degree to which workload, budget and schedule can reliably be estimated upfront
* the payment mechanism you might apply when outsourcing
* the process / software development methodology you should adopt
* your (in-house team) role and the degree of involvement in the development process
* the vendor’s team you should choose to develop your software solution
* the degree of customer / user involvement needed
* the amount of collaboration required to execute successfully

In this way, each project poses specific challenges and calls for tailored solutions which fit the project type and size. Fail to account for such differences, and you significantly decrease your odds of outsourcing successfully.

### **Well-scoped projects**

Going back to the examples cited above – what if you are outsourcing the development of a fairly well-defined project type?

Your initial **scope** definition is known and thus should be complete, unambiguous and consistent. Both functional and non-functional requirements are specified, and scope change management is not going to be a major challenge on this project type. Consequently, the vendor is able to assess the workload accurately before implementation starts and you may expect them to commit to a fixed-price. Likewise, their schedule estimates should be reliable, and they would need a good reason to divert from it. As regards **process**, your accurate initial scope definition means that your collaboration with both your customers/users and the product development team can be less intense. You will obviously have to provide some feedback, monitor progress and accept the deliverables on a periodic basis. Still the team have been provided with sufficient information to execute successfully without frequent and intense communication.

### **Fuzzy and volatile project scope**

What if you are creating a new application or software-enabled business venture with high market risk? You have an overall product concept and high-level requirements but the whole **scope** cannot be specified accurately enough for efficient implementation. Worse, it is likely to change dramatically as you pivot.

Developing detailed specs in this case is a pure form of waste and may lead you to develop a product with poor or no market fit –  a product nobody needs badly enough to use, let alone pay for. What do you do then? Working from the high-level requirements, you develop detailed specs for specific project milestones. The product development team may try to guesstimate the overall project workload, cost and timeline but they commit to budgets and schedules on a per-milestone basis. Some vendors are more comfortable with a time-and-material / hourly rate payment approach but you should pass on some risk to them. In fact, you do have a basis to expect it and that is your well-defined milestone scope. The team should ensure there is an efficient process and tools with which to track scope and its changes as well as their implications for overall cost and implementation schedule. You will need an iterative, agile **process** which requires close and intense collaboration between you (your market team) and  your customers/users in the first place. You do not outsource the whole software development lifecycle (SDLC) – the customer development process and product ownership remain your ultimate responsibility. With an agile approach your collaboration with the vendor will be equally intense. You will synchronise to provide feedback much more often. You may even consider face-to-face collaboration with the vendor, for example, at the beginning, for the fuzzy-front end and design activities or at important moments in the project implementation.

### **So what can you do?**

If you understand the characteristics of the project you want to outsource, you are in a much better position to successfully manage the project scope, the process needed and the team(s) to be involved. And the next time you meet an entrepreneur pursuing [Eric Ries’s](https://www.startuplessonslearned.com/) lean startup methodology asking the development team to quote a fixed-price for the project or, alternatively, hear of a development team charging by the hour for a small, well-specified application, be sure there is a different way which makes much more sense for both sides. Ultimately, they are all in the same boat.

Assuming you want to make profits rather than products, scope is the main driver of your economic results. It ultimately determines the value you will deliver to your customers and, consequently, the revenue you will be able to generate from your product or software-enabled business venture.

Read our articles on Selleo Blog

Business

Technology

How To Run A Winning Kickoff Meeting

How To Introduce A New Developer To A Project

The Product Owners Communication Style Process Adjustments

The Impact Of Initial Project Scope On Outsourced Software Product Development

Tell us about your project