How do I improve the development process when the only 'spec' is a "slogan" from management

Question

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.

Answer 1

As far as I understand the question, and if you allow me some humor, you want to know if it is ok to change a pseudo-chaotic (non-)process into a highly bureaucratic PMBOKful one at once. Based on my experience the answer is no, for several reasons:

1. The team is not trained in such a heavy process and it will take a long time before they are efficient. Not that they are not aware of the problem, but they have been freestyling for a while and it might be hard for them. You probably can't count on them to train the new members on the process, making this team like a completely new team somehow.
2. You don't know - and cannot know - what the best process is for this particular situation yet. Nothing personal here. I really think no-one can find the best process/methodology/whatever on a paper, without trying anything.
3. As you are (rather) new in this company you might experience big difficulties to have your big process accepted by the team.
4. Trying to apply a process that worked somewhere else as-is is probably a mistake. Nothing personal here neither since this is a pretty common misunderstanding in occidental culture that does not exist in Japanese culture for example. We want big results right now. We want it all and we want it now, so we apply the "how" without understanding the "why".
5. You might sound like a grumpy old man : "In my time we would have done foobar..."
6. The team is probably very agile-minded : no process means that things can be changed whenever the stakeholders want. Of course too frequent change requests are annoying, but you should not be too strict neither.
7. The management is probably very agile-minded too. They won't accept a process where they must give all the requirements from the beginning (which is impossible by the way), whereas they used to be able to change everything for free.

In your situation I would recommend implementing a kaizen-driven improvement. Have the team think about the current process (there must be the shadow of something, right?). A manager should be here too. Together make a value-stream mapping of what you do now and try to find out what the main problem is and how to fix it. Of course you will keep in mind your target process but don't be too hasty. Instead try to make everybody involved into the process of changing the process, after all they know that there is a problem with the current situation. Let the new process run for some time and repeat the whole thing in a try-learn-improve style.

As a side-note I'd like to mention that I once was in a similar situation and decided to implement Kanban. You should have a look at it as it could open new perspectives.

Answer 2

Requirements gathering is part of the manager's job, and how it is done depends on both the company culture / current processes, the experience of the manager in the specific field of the project, team members' experience, etc. If you want to introduce more formal planning part, start small. Start with gathering the minimal set of requirements your team can start working with, and try to gather as much information as needed while the team is working. Explain to your managers why some information is critical in the beginning, or plan to have any bit of information changed.

Since the current process is "slogan to product", it seems it's expected from the managers and team members to be very experienced in the field. Invest your free time in learning the business. At the same time, explain to the managers that requiring such experience for doing the job doesn't scale well, so introducing some steps in the planning will help bringing projects up to speed with new engineers and managers.

Answer 3

I heartily agree with Matthias in his suggestion for a Kaizen driven improvement process.

You indicated that there won't be too much push back from the team when implementing you SDLC, but you do need to get buy-in from your stakeholders as you implement the process.

I'd recommend that you take several steps to build a strong process with the team:

1. Bring in a very general, broad set of steps that's not very rigid. This way the management and the team feel like they are still flexible, and you are more likely to get stakeholder buy-in.
2. Implement this on small projects first, and solicit feedback from all team members and stakeholders.
3. Use a Kaizen style of change implementation to have the team fill in the SDLC process. This way the team is building a solid, formal process that works for them.

You'll be able to guide the process toward your eventual goal, and it will be far less disruptive to the team and management.