Start Your Idea

12 Principles To Guarantee Project\’s Quality (Part 2)

In part one of this article, I told you about 6 Principles To Guarantee Project’s Quality. Here are 6 things left to create the perfect quality for a technology project.

7. Hold a kickoff meeting

As the first meeting between members of the project team and, potentially, the client or sponsor, the kick-off meeting is an excellent opportunity to establish expectations and create strong team morale.

Your kick-off is a time to introduce the team to the project, decide on teamwork, and set project goals and check-ins. You might want to outline how you’ll communicate, meet, and what could slow down the process (and how to avoid that).

Our typical project kick-off meeting agenda:

  • Team Roles – introduce team and what they will be responsible for.
  • Vision statement – like “For <customer>, the <project name> does / provides / solves <problem / solution statement>. Unlike <competitor / comparison point>, it will <differentiator>.”
  • Project Scope – You present the MVP features we need to deliver. It would be great to cover also a high-level epic journey: What user personas are involved? Where it fits in the user experience? NOTE: people will know the documentation you provided before the meeting.
  • Timeline and Metrics – Sponsor presents his point of view on Trade-off so we can make smaller decisions quickly and autonomously. Refer to the Trade-off Sliders play for full instructions.
  • Success factors (group session) – to engage people. Ask everyone to write down what they think will make this project a success. Have the team post up their ideas. Discuss how you could measure each one.
  • RAID (group session) – like the previous sessions, but focusing on risks.
    • Risks – things that could happen, and would affect the quality, timing or cost of the project (or a combination).
    • Assumptions – things that are currently true and form the basis for a plan, but any change in them would create risk or issue.
    • Issues – things that have already happened that adversely affect the project.
    • Dependencies – things that need to be done or provided, either once or regularly, to make the project a success.
  • Team communication plan – Here I will discuss how we will communicate – how often, in what form, etc.

8. Prepare and estimate the project requirements using Planning Poker

The project requirements have to be listed out and then estimated. Scrum and agile methodologies approaches require that you create a Product Backlog for this task. Once you have your list, you should leave the estimation to the people who will be working on those items. In Agile management, the estimation must be done by someone on the team to be considered valid.

Planning Poker ends up with assigning a score for each item on the list. Note that scores represent the amount of effort each item will require. They haven’t been attached to a timeline yet.

Planning Pocker estimating method brings multiple benefits for the project:

  • encourages team collaboration and team building
  • conversational style can provoke valuable insights from software development team who might not have a platform to discuss their opinions and experiences otherwise
  • requiring individuals to defend their predictions results in estimates that more adequately adjust for missing data
  • improves estimate accuracy, especially on items with a lot of uncertainty

9. Measure work progress using the definition of “done”

While Agile software development teams are defined as cross-functional, they come with some limits. For example, not every software development project will include a lawyer in their team.

The limited nature of cross-functional teams is used to gauge how much the team will deliver in each cycle. If something appears and it is outside the team’s knowledge, it will be done pre-work or at the end of the cycle or even concurrently with the development team.

To obtain a better understanding of this work you can create an organization-wide value stream map for project delivery. By creating this map, you will find out the amount of time spent on each type of work. If you take out the work that has to be done by the Agile team, you will obtain a clear image of the work that needs to be done outside the team.

The amount of work found in the value stream map is a good start for setting up the budget based on the project’s cycle labor costs.

10. Do risk assessments regularly

Every project comes with risks. Risks are problems that may arise over the course of project development. Project management has the task of identifying and reducing risk beginning at the project planning phase. We recommend you plan a meeting to discuss this or simply ask all the team members about what risks may arise.

When considering risks, you should look into these areas:

  • Project Scope
  • Resources (staff, financial, and physical)
  • Project delays
  • Failures of Technology or Communication

Complete control over all potential risks is impossible, so you should focus on considering them early on to avoid project failure.

Here’s an example of the technical risk management plan:

11. Communicate, Communicate, Communicate

Agile manifesto encourages developers to communicate better by putting team collaboration. When using agile model, the team members work closely with the stakeholders, resulting in improved decision making, and better customer satisfaction. Using task management software can help increase efficiency.

Keep in mind that agile methodology needs solid communication between the client and the offshore development team to achieve project goals and ensure proper software delivery.

Honesty is important in this relationship. Because of some cultural differences, a common situation is that software developers avoid speaking their minds for fear of upsetting the client. Sometimes misunderstandings can appear, caused by filling the knowledge gaps with wrong information.

Frequent team visits and other team building activities are a great addition, but communication tools, outsourcing vendor company culture and business processes guarantee outsourcing model success.

The point is that there’s nothing such as over-communication in agile software development. To set the project for a great result, we recommend setting up as many communication channels as you can.

Communication In Agile

Outsourcing vendor appoints at least one member in their team who speaks fluently in the client’s native language to represent the client accurately. This person’s role usually falls into the categories of Engineering Lead or a certified Scrum professional. You should consider an individual that can hold this responsibility, and it’s known to be reliable.

On the other side, clients have to name a dedicated representative, that is very familiar with the knowledge and can communicate efficiently with the offshore development team.

Poor Communication Strategy

The client’s representative is usually authorized to accept changes or approve work.

12. Continually seek excellence

13 Comments

Leave a Reply

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

  • All Posts
  • Digital transfomation
  • Technology stack
  • Working process
Load More

End of Content.

slitigenz logo

Follow Us On

Who We Are

Discover Our Roadmap

Meet Our Team

See How We Work

What We Do

IT Outsourcing

Offshore Development Center

Dedicated Team

Software Development

Freelancing Team

Updating Technologies

Big Data & Machine Learning

Blockchain

Cloud Computing

Our Creations

Sli Home

GazeCode

What We Offer

Our Deployments

Our Knowledge

en_USEnglish
en_USEnglish