How to Structure Research and Development Phase?
As a person engaged in the bidding process, I go through many requests for R&D services. What surprises me is the fact that inquiries are mainly focusing on the hourly fee per service and not that often on the total costs of developing a product or maturity and processes of the organization that will be used to build the final solution. That is why I am always thrilled with those requests where we are asked not only about the prices, but the processes and project organization as well.
I would like to share with you the idea of the top level processes that, in my opinion, are the most important for the Research & Development phase in IT service projects.
We use the Agile/Maturity approach to project management with different levels and methods applied at the project and development phase. On the one hand, the Maturity plays its role not only in all classic PMBOK processes, but can be used to align with business stakeholders, such as Product Owners or Sales, who are used to planning product development in a bit longer perspective. On the other hand, Agile methodologies like Scrum work perfectly at the development team level, when planning, communication, implementation, fast delivery, and the removal of any impediments are crucial for highly effective and deeply engaged project teams.
Surprisingly, this process is not that obvious for some requestors. Even if the specifications for the products can be prepared in advance of the bidding process, firstly, it takes very good communication skills and engineering expertise to turn them into development specifications/designs. Secondly, you should be really an expert in the platform design patterns in order to make sure that the final User Experience and Information Architecture will deliver an exceptional product. Finally, the Business Analyst is an “interconnector” explaining the product vision and specifications to the development team, and the product philosophy and design to the client.
This area is a must, unless you are developing a back-end Big Data processing on Amazon Elastic MapReduce ;). In all other cases, when the User Experience (UX) and User Interface (UI) are important components of the final solution, this process will be very demanding. We engage internal UI/UX designers working on our premises as discussions about UI/UX are nearly impossible to be managed by phone. Having a UI/UX Designer on board enables the Business Analysts and Developers to talk, challenge and improve the designs at the stages of mockups, designs, implementation and service releases. It also allows them to come out in the other UI aspects of product development, including visual identity, marketing materials, online materials, and good old Desktop Publishing (DTP).
Architecture & Design
Architecture is not that popular, especially for a smaller project. But guess what? There are fewer and fewer smaller projects, and the approach to Architecture and Design can be lean as well. In case you have any back-end components, Cloud or any networks infrastructure, this part is getting obligatory. It will be used by the Service Delivery team to understand your current product architecture. Both Architecture and Design will be used by your development teams to understand the concepts. Last but not least, your Quality Assurance team will use it to design tests and prepare tests scenarios.
This is the type of service clients are asking most often for. Developers will be working on technical designs and specifications; they will take outcomes of Business Analysis, designs from UI/UX Designers and Architecture and Designs and implement them into the solution. By taking an active part in the Sprint planning activity, they will raise any ambiguities or problems in the current specifications or just align themselves with the rest of the team. The implementation involves not only the agreed functionality, but also the agreed level of the automatic/units tests. Following agreed coding standards and the agreed Definition of Done (DoD) enables the team to provide a solution of exceptional quality.
In the IT world, I think we should extend the adage of “certain things” to
death, taxes and quality assurance 😉
I like this role, people responsible for it stay focused, standing a bit aside, and assure that at the end of any task our work will be verified independently. Quality Assurance is a repeatable process which enables one product version to be evaluated against agreed criteria and provides input to the project stakeholders about product quality. In our team we use internally the mixture of ISQTB and ISO29119 to structure this scope of R&D work.
I have seen this process playing an increasingly important role in the game. It takes not only the integration of the source code changes, but also a testing solution on any of the final platforms, the integration with the external and internal service components (yes, architecture again), specified protocols, and different data sources. In many projects I have taken part in, the integration, especially with the external components such as external hardware, measurement sensors or third party interfaces, was the source of most challenges. Luckily, there are more and more services and technologies supporting the automation of those activities, e.g. Amazon Web Services (AWS), and the team can be informed about any problems well in advance.
Last but not the least, Configuration Management. We cover here the R&D team support, management of the development environments, specification and configuration of all the tools, selection and recommendation of the architecture components and so on. Equally important , is the evaluation of third party components from both engineering and licensing perspectives. A Configuration Manager is also responsible for the specification of the final Production environment and provides all the manuals used by the Service Delivery teams to configure, install and maintain the final service infrastructure.
And that would be it when it comes to top level Research and Development processes. Some organizations approach those processes indirectly, others specify them in fine detail. No matter which path is chosen, I strongly believe that the more processes from Software Engineering you embed in the single team/location, the more efficient the product development is. This way you can limit the communication going outside of the R&D team and engage business stakeholders only in the key moments.
And what are your opinions about the minimum scope of R&D processes? Please feel free to share them with me …