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.

  • 2
    I'm not sure what your problem is, here. "How to improve the PM process" is a polling question. Can you address a specific problem that you're trying to solve instead?
    – Todd A. Jacobs
    Commented Dec 22, 2012 at 23:09
  • 1
    Welcome to PMSE, Patrick! I edited the question to hone in on what I think you are trying to get at. Let me know if I'm off the mark. One detail that would be helpful to know is why you can't use the same process that you were using at your previous company? Commented Dec 23, 2012 at 0:38
  • 1
    Hi Patrick. Even after the edits I think the question is still too broad. Maybe you could give details on the current process and tell us about some problems you identified and want to solve. Commented Dec 23, 2012 at 10:59
  • 1
    @CodeGnome. I will be doing some project management as well so I still hope that the question qualifies here. I just need to formulate a good question... I have been thinking about the actual question and I do actually know where I want to end up; I want to have a SDLC (Systems Development Life Cycle) in place that each project can follow. A SDLC would (if accepted by all parties) provide a common process and terminology within R&D. The question is what the road to an accepted SDLC looks like.
    – Patrik B
    Commented Dec 26, 2012 at 22:02
  • 2
    A long rewrite of the question done
    – Patrik B
    Commented Dec 27, 2012 at 10:29

3 Answers 3


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.

  • I will fill in with some details related to your answer. 1. There is a lot of new people and 3 "original" developers. The other new people are also frustrated over the non-process. 2. I have been with the company for 12 months and I have done a few small projects. I can clearly see where the problems are, the solution is of course now as clear. 3. Yes. I would need buy-in from my R&D Manager. 4. Yes, I don't plan on doing a 1:1 mapping. The process I'm thinking about is more agile. 5. True 6. I can say that they aren't to found of all the sudden changes... So does this info change anything?
    – Patrik B
    Commented Dec 28, 2012 at 8:20
  • 1
    Thank you for these details. I will edit my answer to give some more details on the "reasons" part, and make clear that there is nothing personal Commented Dec 28, 2012 at 9:52
  • 2
    We are cool, I know it's not personal! To sum it up; So far I have been thinking hard on where I want us to end up - a new process that maintains development speed and embraces change while doing the work in a structured and traceable way. Now I need to think about how we will get the team to commit to a new development process. And commitment probably comes from participation in the process definition.
    – Patrik B
    Commented Dec 28, 2012 at 12:28
  • 2
    "get the team to commit to a new development process" and the stakeholders, managers, etc. It's important to have everybody on the same page when implementing such a change. Commented Dec 28, 2012 at 12:36

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.

  • 1
    I like the answer. I want to add, that you do not need ALL requirements upfront. If you take a user story there is basically nothing there. But through discussion with stake holders, if gets life. Take the slogan and start working, just don't stop communicating with management about what they really want.
    – rioki
    Commented Dec 26, 2012 at 21:31
  • There is no process in place and how the product is developed is an ad-hock process that will vary over time. So I don't want to start small, I want to introduce some structure that you can do project management on, otherwise it's just chaos management. And I agree, you don't need all requirements upfront. But as this is both hardware and software the overall architecture (with interfaces between domains) must be defined early in the project
    – Patrik B
    Commented Dec 27, 2012 at 7:18
  • 1
    @Patrik: Do you have the necessary political clout to effect sweeping changes to the process at once? Would suggest at least introducing written requirements documents that are drafted by you but initialled by higher management ("the slogan masters") to have a neat check whether you understand each other. Commented Dec 27, 2012 at 18:03
  • 1
    I have been writing requirement specifications for the stuff I got assigned. The reason is that I needed to translate the slogan into something that I understand before I got to work. I have sent these document to my manager and he thinks they are a great improvement. So far so good. So with a little bit of luck I will be able to introduce major changes at once. But is it wise?
    – Patrik B
    Commented Dec 27, 2012 at 20:23
  • 1
    Teach them by example. Show them that formalizing and documenting process brings results by having quicker cycle in your project. Your company undergoes the painful but necessary transition from *'ad hoc'*racy of a small outfit to a mid-sized business. You are invaluable to your firm in that you have the experience to make the transition work smoothly in your dep't. With a bit of luck there will be managers who'll grasp this problem and find a useful ally in you. But don't push it right now, old habits go away slowly. Commented Dec 28, 2012 at 6:02

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.