Project management guide 9 steps to successfully take off Contents
Introduction 3 Check whether requirements have been documented and fixed for your 4 first delivery Check to see if an infrastructure is available 5 Check with designers to determine that the design has been approved 8 and design guidelines have been defined for the project Check that integrations with the customer’s other systems have been 11 defined Check that all team roles have been assigned 12
Check with the PM to determine whether there is a clear picture 13 of the current status Ensure that the team lead or architect has a clear understanding 16 of the target architecture and has real firsthand knowledge of required technologies Determine whether each developer has the require skills for their role 19 in the project Check that QAs have test plans 21 Conclusion 23
2 Introduction
You may have a project that isn’t progressing very well or is getting out of hand, and you need to get it back on track. You may have been recently hired, or perhaps you’ve been working on a project for a while, and you now realize that you are quickly running out of time while critical milestones are not being met. As software consultants, we’ve been in your shoes. For almost 20 years, we have worked with CTOs, VPs of software development, heads of engineering, and project managers who have struggled to build and deliver their software to their customers. They turned to us to help them complete their software development projects on time and on budget. Sure, you could read one of the many books on project management, development processes, architecture design, and various technologies. But you don’t have the time to do that. You need to quickly understand what’s going wrong with your project and determine what needs to be done right now. Based on the knowledge and experience we’ve gained from working with customers just like you over the years, we’ve built a concrete and pragmatic checklist that will help you identify issues with your project and solve them.
3 1 Check whether requirements have been documented and fixed for your first delivery
Unfortunately, too many companies don’t have detailed specs in place. They claim that they are using an agile approach, and they describe functionality when needed. Their business or system analysts write stories and add them to backlog. And, those stories are later retrieved from backlog and included in current development sprints. It appears that they are following agile processes. However, we frequently see situations where nobody on the team knows what needs to be delivered. This brings us to the first item on the checklist. Be sure to create a full description of what should be delivered. Make sure that somewhere in JIRA, Confluence, Basecamp, or Redmine there is a clear definition of the closest customer-facing milestone rather than vague plans. We’ve found that it is vitally important to have a written agreement that clearly defines the scope of the first milestone. There will be enhancements and changes later. But, right now, just fix the scope and document it. Of course, try to have the functionality described as stories and put those stories into your system. Make sure the stories are detailed enough and share them with the team. Then, check that the team understands what needs to be delivered. To optimize your efforts, it’s beneficial to understand how the product is going to be brought to the market. It’s also essential to know what kind of licensing model and trials you will have to support from the very beginning. Finally, there are three more considerations. You must determine what kind of statistics about system use you are going to collect. You must decide how you are going to support the users of the system. And, you must figure out what information your helpdesk support needs 4 2 Check to see if an infrastructure is available
Very often when we first engage with a client, we discover that the customer did not have information about the infrastructure they need. The belief exists that since everything may change during a project, the customer only needs to be concerned about the infrastructure when the software itself is ready. This belief is unfortunate. Because the customer’s infrastructure team might be overloaded with their day-to-day tasks, adding something that is big and urgent to their plate might result in a project delay and delivery failure. So, start planning as soon as possible. Here is a checklist to follow:
1 Check to see whether the customer is going to host your system on-premise and that all required hardware is available. At the very least, all expenses related to this hardware should be thoroughly calculated with precise forecasts about solution performance, scalability, and fault tolerance.
2 Check to see whether the customer is going to host your system in the cloud. If so, determine whether all appropriate subscriptions have already been purchased. 5 3 Make sure that the customer’s team understands how many environments they need to have. In a typical situation, there should be a User Acceptance Testing environment as well as Staging and Production environments.
4 Check to see whether your development team has the required environments. At the very least, there should be Development, Testing, and Demo environments.
5 There may be regulatory obligations. So, make sure that your software and all included libraries, third-party middleware, and operating system software meet all requirements.
6 Ask your DevOps team to configure continuous integration and delivery. Also, be sure to have an information security policy and a disaster recovery plan.
7 Make sure that the DevOps team has a system monitoring strategy in place and that there will be tools such as Prometheus to check services availability. Also, be sure to have other tools such as Graphana to visualize system health in real time so that users can react if critical issues arise.
Item number seven might seem to be too big of a task to handle now. But you must not ignore it. That’s because you always need to know that the code you have right now is working. You must be able to deploy your new system automatically and test to see that it works. Having to automatically deploy a new system might force you to start using Docker containers so that your system components will run. You may also need something such as Kubernetes to orchestrate the Docker containers. Fortunately, the preparation of Docker images is a straightforward task, and good developers can easily write the scripts. The DevOps team can start from there and create the process to build all the necessary environments within days.
6 Here are links to useful tools:
How to quickly create base images of Windows Server that might be used for the entire infrastructure Example of CI/CD implementation using the most popular DevOps tools Popular tools that help to detect software vulnerabilities The most popular solution for static code analysis
7 3 Check with designers to determine that the design has been approved and design guidelines have been defined for the project
It might be required to get your design explicitly approved in writing by the customer’s team when you are working on your first product delivery. While many internal things can be changed quickly, customer-facing items (especially design) might take weeks or even months before the mockups will be approved. It helps to have all mockups in an online design studio such as Figma and provide access to key people on the customer’s team. Once the first two or three typical screens are approved, a set of guidelines can be created and given to other designers so that all new screens will have a greater chance of being approved quickly. This checklist helps you validate that design activities are seamlessly integrated into your development process:
1 Determine whether end-customer representatives and all team members (including designers, developers, QA, PM, and business analysts) have access to the design files. Figma or Sketch, together with Zeplin and Invision studio, can help with developing the user interface. These tools can also facilitate immediate sharing so that you can get fast feedback from the team. 8 2 If there is a business analyst, make sure that all user flows were considered, and business logic was not violated during the design process.
3 Check with the technical lead to determine the feasibility of the implementation of the designed mockups.
4 For mobile development, check that the entire design meets iOS or Material guidelines.
5 Make sure that the main mockups were approved by the customer.
6 Create a UI Guide for all interfaces so that the development team will be on the same page as the designers.
7 Check whether a designer has validated these conditions for each screen:
a All supported screens in all states were designed. b If there is no content, the screen must still look nice. c If there is an error, then an error message must be clearly seen on the screen. d Names and text must fit the buttons in all supported languages.
8 Determine whether there is a special process to manage changes in the design version that have already been sent to the development team. And, to avoid misunderstandings, communicate these changes in a highly organized manner. Then, create a preliminary estimate of the amount of work needed to create a new design before deciding on its delivery date.
9 Make sure that the design team stays in communication with the developers so that any additional questions that might occur in the process of development can be answered.
10 Check that there is a design review process to be followed once the system is tested. Review indentation, font size, colors, icons, etc.
9 11 After the release, establish the practice of giving the product to the end-users for testing. Based on the results, make changes and improvements to the design.
Here are links to useful tools: https://www.figma.com/ https://www.sketch.com/ https://zeplin.io/ https://www.invisionapp.com/studio/ https://material.io/ https://developer.apple.com/design/
10 4 Check that integrations with the customer’s other systems have been defined
It is likely that your system will be connected to other systems. It’s best to figure out what these systems are earlier than later. Also, check that work has been started on defining data that will be imported to or exported from your system. Here are some items to check:
1 Understand what systems your system will integrate with.
2 Check whether these integrations will synchronize data in one direction or both directions. Once you know what the data is, there should be mapping between entities in both the existing system and the system being developed.
3 If data being transferred between the two systems is inconsistent, know what measures will be put in place to synchronize that data.
4 Check that there is access to the test environment with these systems installed.
5 Check that the API for integrating these systems is known. 11 5 Check that all team roles have been assigned
Projects vary significantly in size, and so do the teams working on them. The dev team may consist of several “unit” teams that include module teams and feature teams and so on. We recommend having 3 to 10 people on a team. If there is a team with more than 10 people, it should be divided into smaller teams. These are the roles you should have:
Product Project Scrum Analyst Manager Manager Master 1 2 3 4
Architect Tech Developer Tester Lead 5 6 7 8
Designer Technical Writer 9 10
Practically speaking, you can have fewer than 10 people on a team. However, all of the roles listed above must be distributed among the people on your smaller team. 12 6 Check with the PM to determine whether there is a clear picture of the current status
The project manager is the captain of the ship. That person needs to have a clear vision about where to lead the project team. That person also needs to have the necessary tools that help determine all movement parameters so that they can react if some of those parameters no longer make sense. Here is a list of important things to have in place that will help the project manager steer the ship:
1 Make sure that there is a confirmed budget for the project and product development.
2 Check that there is a project charter that describes all project regulation rules, including the communication matrix.
3 Check to see that you have a project roadmap. 13 4 Make sure that your milestones are defined with dates, not just calculated in man-hours.
5 Check that the project manager clearly understands the limitations in the project from a budget, time, and scope perspective.
6 You must know each day how many features your team has implemented since the last release or milestone.
7 You also need to know how many features your team will need to implement before the next release or milestone.
8 Understand your team velocity in terms of implemented features.
9 Look for bugs. Know how many there are, how severe they are, and whether they persist or not.
10 After every sprint, the functionality developed during the sprint should be demonstrated by the project manager, team leader, or developers. These demonstrations make it crystal clear whether there is any progress or not. You might discover that some team members, or even sub-teams, are not completing important tasks. Discover the reason for this and eliminate the inefficiency. https://azure.microsoft.com/services/devops/server/
11 Be sure to have sprint retrospectives.
12 Check to see whether all decisions and discussions are documented both with the customer and within the team.
13 Maintain project or product documentation.
14 Ensure that a risk management system is in place so that risks are identified and mitigated.
14 It is helpful here to keep track of the following metrics:
1 The number of hours left for the planned scope of work.
2 The burndown rate. Know how many tasks have already been completed and how many are left to be completed before the release or until the end of the current sprint. You’ll find that this graph shows any budget discrepancies.
3 The ratio of the actual budget to the planned budget. If this metric does not exceed one, the project will likely meet the planned budget.
4 The ratio of testing, design, and analytics to development.
5 The number of bugs per unit of functionality.
6 The utilization percentage of the involved resources.
Here are links to useful tools: https://www.atlassian.com/software/jira https://www.atlassian.com/software/confluence http://trello.com https://basecamp.com/ https://www.redmine.org/ https://azure.microsoft.com/services/devops/server/
15 7 Ensure that the team lead or architect has a clear understanding of the target architecture and has real firsthand knowledge of required technologies
The impact that architecture has on any project’s destiny is difficult to overstate. Moreover, the necessity to constantly bring the newest and greatest functionality to the customer, get immediate feedback, and quickly adopt a solution has made the architecture more complex than it was several years ago. The industry standard architecture is based on the microservice concept. While it has many advantages over a monolith application, it brings many challenges that are often not addressed until it is too late to make significant changes. These are general architecture concerns. Having an answer to these concerns will help you verify that required tasks have been completed or will be completed from an architecture perspective:
1 How flexible is the system to new system requirements under the assumption that the system will be developed further?
2 Is the system scalable so that it can handle a system load increase? 16 3 What are the peak loads for the entire system and each subsystem if it has a complex structure?
4 What will happen in case of unforeseen situations, such as failures? Will this lead to data corruption or loss?
5 Has the number of possible concurrent connections to a server (e.g., web users or connections to a database) been estimated.
6 What is the estimated average response delay time when an end-user works with the system? Does this estimate meet requirements from the customer?
7 Were data caching strategies on each layer evaluated? This includes database, backend services, and frontend services.
8 With respect to production upgrades, are any time-consuming data update operations expected? If the answer is yes, then will it be necessary to provide access for the end user at this time, and how will that be done? Also, is Blue and Green deployment methodology planned or will read-only data replications be used?
17 These questions relate to a distributed versus monolith application:
Is your system distributed so If it is a monolith system, then that each part can be deployed 2 do you plan to split the system 1 separately? Or is it a monolith into separate subsystems or application that needs to be microservices? deployed all at once?
If it is already microservice- 4 Is communication based, do you have a clearly between services clear? 3 defined set of rules regarding how decomposition into microservices is done? Are there mechanisms in place 5 to check services availability? Does the design include a health Are logs aggregated across all check of the API? 6 subsystems or microservices?
Do you know what amount of 7 Is audit logging planned? 8 data needs to be processed by each subsystem or microservice? Is the concept of data consistency and data integrity between Is it clearly defined what data is subsystems implemented? Is the processed in synchronous mode 10 data consistency achieved via and what data is processed in two-phase transactions or a saga asynchronous mode? Also, was approach (with orchestration or using synchronous service calls choreography) in place? 9 versus asynchronous interactions through messaging evaluated with analysis of advantages and disadvantages of both approaches?
18 8 Determine whether each developer has the required skills for their role in the project
The bigger the project, the more developers you will have on your team. When the team is large, inactivity on the part of one or more developers can go unnoticed. In our experience we have seen developers who contributed nothing valuable to the project for months. These people made some meaningless changes in the system while devouring the project budget. Once identified, people fitting this description should be removed from the team. There are also developers who contribute something tangible to the project functionality, but they introduce more issues than the benefits they bring to the table. Time is a valuable resource and must be spent wisely. This means that if someone is not an effective team member, they need to be replaced as soon as possible. Here are some things to consider in order to determine whether a developer is a good fit for the project:
1 Can the developer explain what parts of the project they are working on?
2 Does the developer know how to test what they developed as part of a system as well as how to test this functionality separately from other system parts? 19 3 Is the developer aware of any technological shortcomings in the existing code of those modules which they have worked on? Do they have any suggestions for solving any shortcomings?
4 Has the developer considered non-happy cases when implementing tasks?
5 Does the developer know development technologies for those parts of the system on which they are working?
6 Can the developer write tests for the functionality they are working on?
7 Can the developer adapt other developers’ code so that this code can be tested?
8 Does the developer know the level of load in the parts they are working on, including the required processing speed, data volume, and call frequency?
9 Does the developer know how to profile their code and how to optimize it if needed?
10 This applies especially to database developers. Do they understand not only how to write queries but how these queries will be executed, what indexes if any are used, how to profile these queries, and what needs to be done if these queries work slowly? With regards to NoSQL databases, it might be found that the queries cannot be efficient with the existing data structure and the structure needs to be changed.
You can check a code quality here: https://www.sonarqube.org/
20 9 Check that QAs have test plans
In the IT world, there is a belief that testing is needed only when the product has been fully developed. This belief is completely wrong. Companies that wait to fully develop a product before testing end up with a low-quality product and a bad reputation. It is crucial that you test your product at all stages. This checklist includes the items for each stage and highlights the main ideas that are important for successful product testing:
1 Is the testing team sufficient for your project?
2 How are roles distributed among the testing team? The number of testers depends on the project size. However, in any case, there must be a QA lead.
3 Have the requirements been determined and clarified for each stage of the testing? 21 4 Are the described requirements sufficient and consistent?
5 Do you know what OS, platforms, devices, resolutions, and browsers will be used?
6 Are there enough devices needed for testing?
7 Is a sufficient test stand or environment available?
8 Is the entire team familiar with the project?
9 Do you know exactly what documentation is required from the testing tea and in what language it should be written?
10 Is the written documentation sufficient and relevant? In the case of change requests, for example, the Requirements Traceability Matrix must be provided.
11 Are the appropriate scripts written to demonstrate the developed functionality?
12 Do you understand all non-functional requirements and the level of automatization necessary?
13 Once testing is complete, did you notify all involved parties that the testing is complete?
22 Conclusion
If you are in a position where you need to get a project back on track, we hope that this checklist will help eliminate issues that are causing problems. Because we know that mere knowledge of the issues you are facing with your project isn’t necessarily enough to solve them, we are here ready to help. Whether you need assistance with identifying issues or solving them, please contact us. We will go through this checklist together, speak with your team, review the code, and help you solve any problems. Our comprehensive approach looks at the most critical parts of your system and stabilizes them first. Then we work together with you to decide what to do with the rest of the parts.
Give us a call or send a message today if you need help
David Spangler Sales Director – USA [email protected] +1 203 208-6911 www.wave-access.com 23