iSixSigma

Where to Start a Company’s Operational Excellence Journey?

Six Sigma – iSixSigma Forums General Forums Implementation Where to Start a Company’s Operational Excellence Journey?

This topic contains 10 replies, has 5 voices, and was last updated by  Boyan Angelov 3 months, 3 weeks ago.

Viewing 11 posts - 1 through 11 (of 11 total)
  • Author
    Posts
  • #237281

    Boyan Angelov
    Participant

    Hi Experts,

    ISSUE: I was asked to help a with some process mapping and improvement efforts in a small company and I wonder where/how to start.

    The company sells tailor made software and consists of 22 people – 1 sales person, 1 Project Manager and 20 developers. Currently they do not have any processes mapped and and are working as they know.

    Exact problem:
    1. 90% of all projects delivered are delivered with huge delays.
    2. Another thing is that they would like all their processes mapped and improved at a later stage.

    Possible approach:
    Now I wonder whether the approach I was thinking about is the most effective one.

    1. Start building the processes maps from top down. Level 0, Level 1 etc 2.
    2. Aim at the 90% delay issue.
    3. Aim at any additional issues found.

    The questions that I have are regarding what approach to take for step 1 – Can you please share some specific approach/tools so I can research more?
    OR
    Do you think I should use some other approach?
    What would you do in such case ?
    Please share some experience that you have.

    THANK YOU!

    1
    #237284

    Boyan Angelov
    Participant

    Maybe I can use the Baldrige excellence framework?
    Does anyone have experience with it? I would be grateful for some practical high level steps to take.
    Thanks!

    0
    #237289

    John
    Participant

    It sounds like you have an immediate need to resolve your 90% issue for your business. I would start there before trying to map out all your processes. With a small team you aren’t going to be able to complete even a portion of mapping the entire business while still trying to keep the ‘wheels on the bus’.

    My recommendation would be to put together a high level Value Stream Map of your current development workflow. The scope should show from start of project through release of final product. There are lots of articles on this site on how to construct value stream maps as well as ‘Dr. Google’ searching will give you something you can leverage as a guideline and tool usage.

    Once the map is completed identify where in the map your biggest delays are coming from and then attack those areas, by gathering data or creating more detailed process steps, to see if you can impact your delivery time with some quick wins or logical solutions.

    One key is to also reach out to your customers and ask them for feedback. Perhaps they have some insight on what frustrates them, delays they experience, or where they perceive you are falling short.

    Once you get your processes flowing better you may find you have time to dive into company wide value stream or process mapping later.

    1
    #237294

    Chris Seider
    Participant

    I’d begin to get a high level process map started with a team and begin to gather data on time stamps (or date) to get data to begin confirmation of “impressions” people will have.

    At the same time, be sure to confirm quickly validity of the data for preciseness AND see if the past impression of lateness can be confirmed for time. This will be good for understanding at least one primary metric of cycle time.

    1
    #237302

    Boyan Angelov
    Participant

    Thank you very much, guys! I think I should follow the approach suggested. First, fix the big problem to free up resources and then focus on documenting the current organization state.

    I will follow up with more details when I have them.

    Meanwhile, please do not hesitate to share additional feedback or more ideas as well.

    Wish you a great weekend ahead!

    0
    #237390

    Boyan Angelov
    Participant

    Guys,
    There’s further development on that story.
    I am still putting my thoughts in order and I would really appreciate your professional hints.

    It looks like the biggest pain point of the team is the development phase.
    Only one product will be targeted for now. There are 4 developers working on 10 different projects related to 1 product. The devs are profiled and 1 is professional in only 1 area.
    There is quite a big backlog of development tasks further to be done.
    The team is using a mixture of Agile and Kanban – Some tickets are being estimated, some not and placed on Kanban board. However, they are not pulled but pushed by the Project manager which ‘breaks’ the kanban idea.

    The top issue is the backlog of dev. tasks that are taking away any time possible to focus on current tasks. If you even assign the top priority ticket to a developer, he/she has so many priority 1 tasks so no focus can be placed on the new one and the delay can be counted in weeks.

    Could you please advise your approach in such case?
    How to focus on properly setting up a working structure that will enable clearing the backlog over time + focusing on any urgent/immediate issues needed?
    Any experience in such? Maybe even similar experience in a production environment to be able to fulfill huge backlog + incoming urgent requests with limited resources?
    Or maybe advise how to prove that additional developers are needed? – On this point I was thinking about a time study to check how much actual time is invested by dev, how much is wasted in additional tasks and then check the existing backlog time estimation?

    THANK YOU!!!

    0
    #237528

    Mike Carnell
    Participant

    @bangelov Why is all of your thinking in terms of tools. You said “90% of all projects delivered are delivered with huge delays.” Delays from what? I would assume a target date. Where did the date come from? How was it calculated? If 90% miss then why do we keep using the same process to create a delivery date? Will the customers say anything if I give them a real date?

    You don’t even understand your problem and you are locking yourself into tools. You need to figure out if the process is really a problem or is your sales estimating method the problem.

    0
    #237559

    Boyan Angelov
    Participant

    Thank you for pointing out the bigger picture Mike! Actually the Project Manager in the company had started evaluating the current tasks needed to complete the development phase in order to fully evaluate the end to end time needed to be invested in order to deliver a project to a client. The Sales person is using some sort of older/own evaluation of when a project could be delivered.

    I wasn’t sure that this would have been the correct approach and I wanted first to see the real value stream and how much time is being wasted between stages, what is the real takt time for dev. tasks , and now we will be working in both direction:
    1. Evaluate each single sub task that needs to be completed by the designer and developers team in the different stages.
    2. Evaluate the lead time between steps in order to build the expected critical path and to confirm it with a new project.
    1+2 = something like the Karen Martin’s – Metrics Based process mapping.

    3. Evaluate if additional people(freelance) are needed to clear the current backlog overtime.

    Thank you for the comment and guidance!

    0
    #237575

    Mike Carnell
    Participant

    @bangelov I am going to make a recommendation that is going to make me sound like I am just regurgitating the current dogma and I apologize. If I do a process map I will typically miss the queues between steps. If you are as backlogged as you say then you probably want a Value Stream Map (I don’t like that suggestion because that seems to be the go to tool for everyone who has no clue what to do but they want to look like they are doing something). The VSM graphically displays the effects of queues very effectively.

    If I go to your second post then it sounds like your bottleneck is at the first step. If that is true then the rest of the process should be sitting on their hands. If that is true then you need to flex those people in the back of the line to assist with back log issues.

    If you have your original schedule data then I would put it in a regression analysis. Very simple scheduled time on one axis and actual on another. You know they are going to be different since you are missing delivery dates but it creates a graphic that is easier to understand for the more/perceived technical type people. Once you use data then it become more difficult to argue your analysis with you. It will also give you an equation so you can let that same person bid it and then run the equation and you should get a more realistic number.

    When you do #1 make sure as part of your evaluation you determine Value add and non value add. Do your best to get rid of non value add but be prepared to have some emotion get into the conversation if you want to eliminate something.

    I like #3. Get that backlog down so you get the emotion out of the picture. If you do that then you need to put some type of metric in each step of the process to manage the backlog. It keeps people aware of the issue and you need to make then accountable for keeping it under control.

    I would start thinking visual factory. I know you are not a “traditional” factory but the concepts behind visual factory apply to your process.

    0
    #237588

    Strayer
    Participant

    It’s often noted that software is different. You aren’t repetitively making things that conform to the same specifications. Every product is new. I’m glad to hear that your company uses agile and Kanban, which were developed to incorporate lean and reduce waste for one-off products. I’ve found that process maps, even value stream maps, aren’t very useful for agile software development. The only thing common between projects is the high level process. The reaction from teams is, “Well, duh. We get that. But we still have to discover what we need to do as we go along.”

    90% delivery with huge delays is far from typical for agile software teams. This suggests a lack of training and expertise, especially for team coaches (project managers). The transition from traditional project management to agile is not easy since you have to cast aside so much, such as detailed work breakdown structures, PERT estimating, detailed requirements, and so on. You might want to tactfully look into how well your organization is prepared to do agile before you try to analyze what’s wrong with the process and force-fit an improvement.

    0
    #237589

    Boyan Angelov
    Participant

    Thank you for your valuable thoughts and expertise!
    It is definitely beneficial to ask someone who already got through similar scenario instead of re-inventing the wheel.

    Will keep you posted once there is development on the topic , so maybe it can summarized in to a case study later.

    0
Viewing 11 posts - 1 through 11 (of 11 total)

You must be logged in to reply to this topic.