Facebook EmaiInACirclel
Product Strategy

[Episode 01] The right processes for the right needs

PentaGuy
PentaGuy
Blogger

For several weeks now we have been working within the “Software and Applications” department of the ISD on defining the processes related to software development. The development of specific tools represents 95% of our activity, compared to license tools. Indeed, we have decided that Pentalog was also a “software solution” made up of the tools that we develop ourselves and OpenSource tools. Development processes are therefore essential for the functioning of this department.Our approach on processes didn’t consist in including all our activity in a single process, as this wouldn’t have been precise enough for the teams which must implement them and, given the diversity of activities, there would have been differences. Therefore, we have decided to establish four processes that correspond to the activity of the department:1. Innovative processThe objective of this process is to take into account projects that include a significant amount of research, following which results are not guaranteed, as the technological path that is taken may lead to a dead-end or to failure. It is therefore necessary to have a process that accepts it. Even though the Labbs (http://www.pentalabbs.com) has been created for R&D approaches, this department must know the process well as it must also be able to propose (or answer) its customers on specific cases, outside standard practices. Of course, these projects are the most likely candidates for RTC (research tax credit). It is for this reason that the process includes the documentary requirements of this system.2. Rapid processThe urbanization of our IS relies on a series of applications that are aimed at a specific professional need and integrated into an SOA/BPM architecture. This process is therefore very important for providing the responsiveness required by customers. These small applications whose workload would be less than 100d (project management included) are aimed at quickly deploying vertical, simple and solid applications on tested technologies and methods; human resources must also be prepared. Several quick processes could be linked together, but the approach will not consist in conceiving large projects in this manner at a certain moment; we must adopt an industrial process in order to have sufficient guarantees.3.Industrial processStrategic and important projects with a long-term deadline will be developed according to this process. We are envisaging a complete development process with all its precise control phases. For this type of process, we will deploy the process that is used by the Pentalog production which is currently trying to achieve compliance with CMMI objectives. All our best practices will therefore be used for carrying out these ambitious and sensitive projects: Capitalization of knowledge, Continuous improvement, (Automatic) Code review, continuous integration etc. We will even go as far as to integrate automatic tests within these projects.4. External tool integration processAlthough our main approach relies on the use of our own tools developed in our “factories” in Brasov and Hanoi (where this department is based), we are not saying no to the integration of external tools. We have already integrated business tools on a large scale (Mantis, Testlink etc.). In fact, Mantis has a wide range of uses (managing actions related to continuous improvement, interrogating the administrative and financial department etc.). We are therefore preparing this process based on the compatibility of external tools with our IS integration rules, but also based on helping users to get used to these tools and especially to capitalize on knowledge.Of course, in parallel with all this, we have the application maintenance process once the application has been released. But I will tackle this subject in a future article.For each of these processes we have defined rules and conditions:- What are the eligibility rules of a project for a process? Not all of them have to be innovative or industrial through particular terms or requirements. The size (workload), complexity, project risks, future evolution of the application… are the main criteria that we have established.- What are the technologies accepted for each process? Even though our IS was once a showcase of our technological capacities, we are narrowing our technological scope in order to ensure wider coherence and better team competence management. By limiting our technological scope, we must be able to reuse components on a wider scale. Indeed, as regards components related to SSO, WebServices, Graphic interfaces, BPM, if we put together a component library, we are going to generate substantial gains in the production of our tools.- What are the assessment rules of a project workload? According to the chosen project, we will be able to apply different work units per process, which will systematically be based on a common counting method. Indeed, as with these different processes, tasks are not the same; we establish different matrices that assess everyone’s tasks based on the process.- What are the conditions for going from one process to another? We can start an application based on a rapid process and then transfer it to an industrial process, as the eligibility criteria have changed in time. We have therefore established certain well-thought-out limits, but nothing will be systematic.- What are the clients’ requirements? For a process spanning over a few weeks, reporting-related requirements (content, frequency etc.) are not the same as for a project of several man months or years. The same goes for the client’s involvement in the project. Upgrading requests are also organized differently. The client’s requirements must therefore be adapted.- What are the financial rules of the project? Indeed, we must consider as soon as possible whether a depreciation system is possible and what parts of the project are concerned. Depending on the project, we must also ask ourselves what could be integrated in the RTC system.- What are the governing rules of the project? Although eligibility criteria are well defined, the project assignment decision depends on a committee that ensures project management so that client, department and management requirements are taken into account.- What are the common requirements for the different processes? We are going to manage different “speeds” within the department. However, we must maintain coherence on the whole: project management (expected time/time spent/remaining workload), requirement traceability, test case writing, delivery cycle should be included in this common basis.- What is the impact on human resources? We haven’t taken a permanent decision yet on whether employees are to be assigned to certain processes (very good knowledge on processes) or they can switch between processes. I would go for a gradual adjustment in order to ensure flexibility within the organization. At any rate, we have envisaged training sessions for our teams so that this vision of our organization is shared.- What are the expected benefits? By adapting the process to needs, we are also adapting the process to the deadline of expected benefits. Rapid processes must quickly generate benefits, the lack of which may mean that the project is not essential.- What are the rules for integrating new tools in the IS? We have also defined the rules for integrating tools in the information system in order to guarantee a coherence of our practices within graphic interfaces, communication capacities (WebService / BPM), performances and the required security level.We cannot design everything in a workshop or a factory. This department is therefore organized as a factory and workshop in order to meet our clients’ (and colleagues’) needs in the best way possible. The next new tools will therefore observe these eligibility rules. In a few months, I will communicate (in other episodes of the saga) the measured benefits of these different approaches for the project team and our contact persons.All these choices are being integrated by Iulia (the head of department) in an SQP (Service Quality Plan). We are thinking about the possibility for the Infrastructure department of the ISD to apply the same approach.End of episode one. Are you interested in finding out what happens next?[Prologue] The saga of a value catalist


Leave a Reply

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