I am working in a new environment where a typical project consist of a “slogan” provided by management and a team of engineers who delivers a product that matches the slogan. The company doesn't have any R&D process and the consequence is that the development becomes ad-hoc and mistakes are made. Examples of mistakes; - The slogan is misinterpret – R&D delivers the wrong product - Development starts without requirement analysis – we might end up in a dead end due to technical problems. - Technical documentation is fragmented and inconsistent. As there is no development process in place the documentation is also ad-hoc; there is no requirement documentation except from the slogans and the technical documentation is fragmented and in various formats.
It is a small business mentality in a company that just became a little too big.
The good thing is that one of the tasks assigned to me is to address these problems. We are currently less than 10 engineers (mechanics, electronics and software) but I would expect us to grow in the years to come so I would like to make a serious attempt to do something good. I have been thinking about this for quite some time and I would like to apply the following SDLC to on the organization;
- Formal phases (startup, planning, development, Verification & Release, Follow up).
- Reviews for phase transitions where each phase needs to have its deliveries in place
- Management signoff for phase transition and release approval
- Risk analysis and risk management
- Documentation plans where the documentation is part of a document structure
- Regular meetings with the members of the project team and the stake holders
How can I manage the pain of transition? Is it even wise to try to apply something so rigorous on an inexperienced organization? I don’t want to scare my coworkers or the management. So I don’t really know how to handle this.
I’m currently leaning at writing a SDLC that describes the process, educate the development team and that apply this process on one new project and then take from there.
MY BACKGROUND I have been working in a regulated multi-disciplinary engineering environment for almost 15 years and I'm used to strict project management. We were using a project management model which was based on 5 phases; (0)Startup, (1)Planning, (2)Development, (3)Verification & Release, (4)Follow up where the permission to move to the next phase required that you had fulfilled the deliveries for the phase. My main profession is software engineering as a software Lead, but I have also had responsibilities as sub-project manager and Scrum-master. When we were using agile methodologies for the software team we used them in phase 2 and 3.