Mastering Embedded Systems

In the first session about root-cause analysis we have introduced the 5-Whys technique. It has its benefits, but also some severe disadvantages. As one of the most obvious ones the limitation on one root-cause can be highlighted. In this episode the Ishikawa technique will be introduced. The Ishikawa-diagram could be assumed as the big brother of the small 5-Whys. The Ishikawa covers all the limitations of the 5-Whys and provides a great way to also handle multiple root-causes and more complicated effects. But it also has its disadvantages and pitfalls. Root-causes and the Ishikawa technique The Ishikawa-technique is a graphical approach combining both, Brainstorming and Mind-Mapping. It is a valuable technique for group sessions. You will be astonished how progressive and fast you achieve results using the Ishikawa-approach. If you need to dig deeper in your root-cause finding, then you will sooner or later be confronted with Ishikawa. Take this episode as your personal guidance to get an instant understanding how the technique is done. Moreover take my experiences with Ishikawa to circumvent usual problems and overcome common obstacles. Essential Know-How Provided In This Episode: What helpful tools can be used to create an Ishikawa-diagram? Are there templates for the Ishikawa? When should Ishikawa be used preferrably? Which predefined categories of causes could you use in your Ishikawa? What’s the difference between sufficient and necessary? How mind-mapping can assist you with Ishikawa? And much much more Possible categories of causes Traditional: Man, Machine, Milieu, Material, Method, Measurement 4 P’s of Marketing: Product, Place, Price, Promotion 7 P’s of Marketing: Product, Place, Price, Promotion, People/Personel, Process, Physical Evidence 5 M’s of Manufacturing: Machine (technology), Method (process), Material (includes Raw Material, Consumables, but also Information) 5 S’s in Services: Surroundings, Suppliers, Systems, Skills, Safety 7 S’s of McKinsey: Strategy, Structure, Systems, Share Values, Skills, Style, Staff My favorite: Measurement (inspection), Milieu (environment), Equipment, Material (Information), Methods (Processes), People, Management Selected Links and Resources From This Episode Cause and Effect Fishbone Diagram Work visually, agile and boost your creativity and project with Stattys Thank You For Listening Out of all the podcasts available in the Internet you tuned into mine, and I’m grateful for that. If you enjoyed the episode, please share it by using the social media buttons you see at the bottom of this note. Also, I would be very happy if you would consider taking the minute it takes to leave an honest review or rating for the podcast on iTunes or Stitcher. They’re extremely helpful when it comes to the ranking of the podcast. For sure I read every single one of them personally! Or, if you prefer a more direct contact, don't hesitate and drop me a note at feedback@embeddedsuccess.com The post Finding root-causes with Ishikawa – MES014 appeared first on Embedded Success.

Tools and Building This episode is about building, maintaining and distributing tools and operating system in large scale projects. With Robert Schiele an expert on all this kind of topics stays with me. He is senior specialist for developing OS-tools, providing toolchains and building operating systems. Robert provides dedicated and verbose insights into the Linux Kernel and the Linux Operating System in particular. He’s one of the guys I know who is eagerly engaged into the OpenSource-community. In his current role he maintains development tools and OpenSource components for a global mobile network supplier. His main task is to provide running build-systems, tool-chains, toolsets and root-filesystems. He has seen and resolved a lot of problems when providing tools and operating systems. Especially for large scale systems and multiple hardware platforms in multi-site environments. We’re talking about build-systems, root file systems, native and cross building. We tackle observable problems with distributed environments. We discuss about struggles with multiple hardware platforms. And we give you a close look into the way how well prepared tools-provisioning saves you time and prevents waste. Essential Know-How Provided In This Episode: What are the main challenges when building large scale systems? How can a good building system support you or waste your time dramatically? When to prefer individual build-system over stock products? How to handle circular dependencies? Why is it a very bad idea to put timestamps into your code? What are the benefits of supporting a hardware platform you’re not even using? And much much more Selected Links and Resources From This Episode Open SuSE build system Thank You For Listening Out of all the podcasts available in the Internet you tuned into mine, and I’m grateful for that. If you enjoyed the episode, please share it by using the social media buttons you see at the bottom of this note. Also, I would be very happy if you would consider taking the minute it takes to leave an honest review or rating for the podcast on iTunes or Stitcher. They’re extremely helpful when it comes to the ranking of the podcast. For sure I read every single one of them personally! Or, if you prefer a more direct contact, don't hesitate and drop me a note at feedback@embeddedsuccess.com The post Engineers’ talk: Tools and Building with Robert Schiele – MES013 appeared first on Embedded Success.

How to struggle with your explanations? All the day you might run into the situation to explain problems, defects, situations or environment. Very often your listener or the audience is not aware of the underlying technical details. Or they do not have the knowledge to understand the details at all. This episode tells you 6 ways to struggle for sure with all of your explanations. But it also shows you an approved ways to convert even very complicated nerd details into an understandable manner. Be sure that you struggle If you want to ensure your failure follow these six behaviors: Go deep into details Use inadequate language Assume too much knowledge Drop facts and connections Be impatient if the listener does not understand initially Assume that after your presentation everything is clarified If you follow at least half of them you can be assured that your description of the situation will not be understood by anybody outside of your knowledge. A perfect way to stay inside of your cage of expertise. However, if you want to provide better descriptions, more understandable reports or you simply want to be understood if your run into problems, then have a look at the next paragraph. How to explain exceptionally? People understand stories. People like stories. And people like comparisons. If you start to describe your situation with a picture, then that’s already a big step forward. A picture is worth a thousand words. But the problem might be to find the right picture. Or to strip down the picture to the very basics the audience gets the point of your problem. A different approach, I reguarly prefer, is a metaphor. A metaphor is a comparison which does not emphasize the differences, but the similiarities. That means you pick and idea out of your experience. This idea should be common to your audience, too. Then you compose a story or the comparison around this idea to explain the much more complicated other situation or problem. The essential point is that you have understood the pattern or the skeleton of your situation. You need to abstract this pattern and look for similiarities to find an appropriate metaphor. Let’s assume you have drawn out this pattern. Then you can use the following anchor-points to find the story for your metaphor: Take something out of your environment. Something around you. Look for similiarities in your direct surroundings. Pick natural topics like fruits, trees, wood, animals, techniques, mechanics, etc. Something your listener should be familiar with. Use common understanding topics. DO NOT USE politics, religion or ethics for finding metaphors. They might be misunderstood or offensive. Be as exact as possible. Find a metaphor which is not failing at once. But do not exaggerate. There is no need for absolute correctness. Only the original situation will fullfill such a request. Let the audience rephrase the situation. This lets you check what exactly they have understood. Do not get stucked on a wrecked metaphor. If you remark that your metaphor is failing in some particular point, do not hesitate and rephrase it. Introduce additional details or restrictions. Or drop it finally and take something else. With every approach, with every tail, with every explanation, your audience will grasp a little bit more of the original topic. Thus any failing metaphor is also an indication that your audience gets more specific and closer to the subject. You need to excercise a lot to tell metaphors quickly. It’s a lot about fantasy, but it’s also a lot about extracting the pattern of the situation. You need to lift yourself onto a meta-level of the situation’s description that you can use metaphor’s gracefully. Excercise a lot. Throw away metaphors as quickly as needed. Try another one. Your audience will be happy to see your effort and your eagerness to let them understand. Thank You For Listening Out of all the podcasts available in the Internet you tuned into mine, and I’m grateful for that. If you enjoyed the episode, please share it by using the social media buttons you see at the bottom of this note. Also, I would be very happy if you would consider taking the minute it takes to leave an honest review or rating for the podcast on iTunes or Stitcher. They’re extremely helpful when it comes to the ranking of the podcast. For sure I read every single one of them personally! Or, if you prefer a more direct contact, don't hesitate and drop me a note at feedback@embeddedsuccess.com The post 6 ways to struggle with your explanations – MES011 appeared first on Embedded Success.

How this podcast is produced This is the vacation episode. Recorded on my way to the beach of Moliets-et-Maa. Moliets-et-Maa is a small village in south-west of France. It’s situated close to the Atlantic sea. Roundabout 120 km south of Bordeaux and 50 kilometres north of Biarritz. It’s a surfer’s spot and offers a 9- and 18-hole golf course. We love it due to the great sea view, the wide beach and the lovely weather conditions. It’s also my 10th episode and therefore time for a short celebration. Hoorray. Okay, that’s enough.   5 steps to produce a podcast episode I wanted to give you a short insight how the episodes of this podcast are meanwhile produced. You will learn about planning an episode. The way it is recorded. And the details about post-processing and releasing. Finally I will add some details about promotion. Enjoy! The tools I use MindMeister is my mind-mapping tool for planning the episode’s content. I also use it during recording as my cheat-sheet audacity is a free, open source, cross-platform software for recording and editing sounds. I heavily use it to remaster my recorded sound files. There’s also Adobe Audition, but you will have to pay for it. auphonic is the automatic audio post production web service for podcasts, broadcasters, radio shows, movies, screencasts and more. I use auphonic for my final normalization and loudness amplifying to achieve a constant level of volume in my episodes. Rode is the manufacturer of great microphones. I regularly use the NT1-A, but in this episode the SmartLav+ is in use. dig.ccmixter.org is my preferred source for royalty-free music following the Creative Commons Licence buffer.com is my preferred tools for scheduled contributions to Twitter and LinkedIn. However buffer is much more. Get yourself a try. Thank You For Listening Out of all the podcasts available in the Internet you tuned into mine, and I’m grateful for that. If you enjoyed the episode, please share it by using the social media buttons you see at the bottom of this note. Also, I would be very happy if you would consider taking the minute it takes to leave an honest review or rating for the podcast on iTunes or Stitcher. They’re extremely helpful when it comes to the ranking of the podcast. For sure I read every single one of them personally! Or, if you prefer a more direct contact, don't hesitate and drop me a note at feedback@embeddedsuccess.com The post How this podcast is produced – MES010 appeared first on Embedded Success.

Root cause? What’s that? Remember your last sickness. Caught a cold or a flew? Weren’t you only curing the symptoms? Usually nobody cares for the real reasons when getting ill with these small diseases. But there are lots of persons who are able to somehow avoid any disease. What’s the difference? Why were you felt sick? It’s like weeding your garden. Very often only the symptoms are cured, but no real solution can be achieved. The weed gets back soon. Removing the root would do the job, but that costs additional effort, back-pain and time. Within the business context regularly the management requests an immediate, complete, fast and reliable solution of problems. But is that possible without finding the real cause of a problem? Without fixing the real cause of a problem it might pop the same way again as the weed does. That’s the ideas of root cause analysis. Dive deeper into a problem to find the real underlying cause of the problem. The diving should be that deep to find not only a cause, but the process which is failing or is insufficient This episode is about the first and basic technique of finding the real root cause of a problem: the 5-Whys technique 5-Whys to find the root cause The 5-Whys is a technique first time introduced by Toyota within the Toyota Production System (TPS). It is an iterative question-asking technique to explore the cause-and-effect relationship underlying a particular problem. The technique belongs to repeating the question “Why?”. Each question forms the basics of the next question. The “5” in the name derives from an empirical observation on the number of iterations, which is typically required to find the real cause of a problem – the root cause. The idea of 5-Whys is to dig deeper. But it’s even more. It not only stupidly asking Why, Why, Why again and again. It’s a change in the paradigm of evaluating the cause of a problem by not getting stucked with the symptoms. It’s like unveiling an onion. You work from one shell to the other until you come to the nucleus. Benefits of 5-Whys The 5-Whys technique has several benefits: It helps to identify the real cause of a problem It uses small incremental steps to improve the situation It is one of the simplest tools; it’s easy to complete without any statistical analysis It also determins the relationship between different root causes of a problem The 5-Whys is most useful for problems involving human factors and interactions, like handling, reactive, planning, or design problem. However complex problems might benefit from a more detailed approach. Hereby the 5-Whys can deliver useful insights. Criticism of 5-Whys The 5-Whys technique has several disadvantages and is under critique for: its tendency for investigators to stop at symptoms rather than going on to lower-level root causes. its inability to go beyond the investigator’s current knowledge. You will not find causes that you do not already know. its lack of support to help investigators for asking the right “Why” questions. its possibility to provide different results for the same analysis. Results are not repeatable. Different people using 5-Whys come up with different causes for the same problem. its tendency to isolate a single root cause, whereas each question could elicit many differenr root causes. its lack of supporting multiple reasons for a problem. You will have to decide to follow one path only. How to 5-Whys Nevertheless “5-Whys” is a great tool to start with the root-cause analysis. It is fast, in an elaborated hand very effective and therefore efficient in an outstanding way. To improve your understanding of how to do the 5-Whys I have these 3 steps to follow: Start the 5-Whys Start with a description of the problem by providing answers on these questions: What has happened? Who was engaged? When does it have happened? Who has detected the problem? What impact does the problem have? Best thing first is to invite for a meeting to start the 5-Whys questioning Do the 5-Whys First you should define a 5-Whys master or moderator. This should be an elaborated person who is able to work on a meta-level of the outstanding communication. It should not be one of the major stakeholders, if he have the tendency to fell blamed for what has happened. Start with the first “Why” question Note the answer and validate it by reversing the statement and validating the statement. Example: Q: Why do I have forgotten my keys today morning? A: I have forgotten my keys because I was in a great hurry Reversed: If I would have been not in a hurry today morning I would have not forgotten my keys? Right or False? That’s not a clear conclusion! That’s not the cause of having forgotten the keys. Check for additional causes. Eventually us a parallel path of investigation. Ask “Why again” After some iterations and you got the impression to be done change the question to “Why does our process have failed?” Especially the last step is the most essential one. This changes your perspective from symptoms and easy causes towards a general view. This is the starting point of real improvement. Knowing the failed process is a cornerstone in becoming really better. Report the results of 5-Whys If you have digged out one or multiple root-causes for your problem, then summarize the results: Provide the historical data Highlight the priorities of the different problems (perhaps by using a Pareto-chart or similar) Show the results of the 5-Whys Provide first ideas of corrective actions and their verification Pay attention Please be aware that the 5-Whys are simple in concept but sometimes tricky in reality. The following 3 aspects are essential to keep an eye on: Many times teams will stop once a reason for a defect has been identified. These conclusions often do not get to the root cause. A disciplined 5-why approach will push teams to think outside the box and reach a root cause where the team can actually make a postive difference in the problem, instead of treating symptoms. Avoid intentional or unintentional bias while answering! Find the right person who can answer the 5Why’s! Use other RCA Tools if you’re getting misleading answers. Do not ask your coworkers again and again for the Why. Do not upset them. Summary 5-Whys are living from experience and excercise. Don’t be impatient if the result is not that good in the first usage. Using it continuously will give you the expertise to do it quicker and more elegant. Don’t hesitate to improve! Thank You For Listening Out of all the podcasts available in the Internet you tuned into mine, and I’m grateful for that. If you enjoyed the episode, please share it by using the social media buttons you see at the bottom of this note. Also, I would be very happy if you would consider taking the minute it takes to leave an honest review or rating for the podcast on iTunes or Stitcher. They’re extremely helpful when it comes to the ranking of the podcast. For sure I read every single one of them personally! Or, if you prefer a more direct contact, don't hesitate and drop me a note at feedback@embeddedsuccess.com The post Finding root causes with 5-Whys – MES009 appeared first on Embedded Success.

Launching a task-force successfully Before you start running a task-force you will have a short moment or phase of planning and launching it. You should use this time carefully and wisely. Potential flaws during this phase might be a constant burden over the whole run-time of the task-force. I’ll show you the questions and the actions you need to successfully launch your task-force. Why do we need a successful launch phase? The launch or kick-off phase of a task-force is like the take-off of an airplane. Even it takes off the conditions might be not good and the overall journey might have started already under a bad star. Key indicators of a successful launch phase What has to be done? The objectives! What has to be considered? The constraints! Who and what do we need? The members! the environment! When and where? The schedule! 3 mandatory actions for a successful launch The following three actions shall support you in your intention to launch a task-force successfully. 1st Action: Define You need to define the objectives and the needed resources for the task-force. Use the SMART-criteria to define the goals and targets of your task-force. Pay attention to also clarify the knowledge and actions which are needed for your task-force. Objectives and resources are needed for the next action. 2nd Action: Organize This is the major part of your preparation action for the task-force. There are three different parts you need to have an eye on: Participants should be selected … by their knowledge of the problem, the system, the technology or the methodology; whether they are affected by the problem or the objectives; whether they are involved into the creation or invention of the problem; whether they are involved into evaluating, finding or testing the situation the problem has been observed; whether they could provide a strong push and/or support to your task-force. The schedule Your task-force should be schedule on a rule of thumb once per day. Usually you do not need more. However if there are extraordinary circumstances or outcomes, then it might be needed to meet more often. For example testing unveiled totally different results of the situation. Or you have team-members in two time-zones that far apart they do not meet each others during regular working hours. But in general keep in mind: as long as needed, as short as possible. The invitation Over the years I collected some details which should be contained in an informative invitation. Follow my Meeting invitation template to provide a meaningful invitation. Please remember that your task-force members will be more willing and more supportive if they immediately understand the purpose and the situation. 3rd Action: Handle limitations During the launch phase you usually run into two different limitations: You do not get the persons You do not get the time, environment or the budget For the first my preferred way of working is to decide. If it is not possible from your perspective to fulfill the work without the person you need, decline the task-force. If you do not get the needed expert, but you see a chance to achieve the goal, then accept. But request to get access to the expert on demand. Or accept a substitute which has direct access to the expert. With both approaches I have made good results. For the second and if it is totally out of mind, decline the task-force also. An unrealistic approach needs to be highlighted in such situations. However if it is realistic, then accept with restrictions. Outline crystal clear what you can achieve with the limitations. To provide such statement reliably you need to have a deep insight view of the problem. Thank You For Listening Out of all the podcasts available in the Internet you tuned into mine, and I’m grateful for that. If you enjoyed the episode, please share it by using the social media buttons you see at the bottom of this note. Also, I would be very happy if you would consider taking the minute it takes to leave an honest review or rating for the podcast on iTunes or Stitcher. They’re extremely helpful when it comes to the ranking of the podcast. For sure I read every single one of them personally! Or, if you prefer a more direct contact, don't hesitate and drop me a note at feedback@embeddedsuccess.com The post 3 mandatory actions to successfully launch a task-force – MES008 appeared first on Embedded Success.

Talk with Marcus Behrens about IoT Marcus and me joined the IoT-TechDay in Frankfurt end of June. The IoT-TechDay was a one day conference organized by WindRiver, Intel, SalesForce, SAP, Accenture and Microsoft. The intention of meeting was “Moving from talk to transformation” creating business opportunities around IoT. Marcus is a wholehearted engineer and Product Design Director at SAP in Walldorf, Germany. He’s responsible for evaluating the potential of IoT and finding product ideas and opportunities for SAP. On the other side he was and is an engaged engineer within Embedded Systems. This combination made me curious and we have had a good talk already at the IoT-TechDay and later on by mail. Our opinions about IoT and it’s potential, risks and challenges are not always the same. But that makes this talk even more exciting. Enjoy the episode. We’re talking about: Our experiences and impression of the IoT-TechDay What IoT really means for us Chances and opportunities of IoT The technical challenges of IoT Potential security problems and legal restrictions Outlook on IoT Show Notes Kevin Ashton’s RFID-article first time describing the term Internet of Things Marcus Behrens’ illuminating by mirror on opposite side of valley project Internet of Things Technology Forum: Moving from Talk to Transformation (Keynote session materials)   Thank You For Listening Out of all the podcasts available in the Internet you tuned into mine, and I’m grateful for that. If you enjoyed the episode, please share it by using the social media buttons you see at the bottom of this note. Also, I would be very happy if you would consider taking the minute it takes to leave an honest review or rating for the podcast on iTunes or Stitcher. They’re extremely helpful when it comes to the ranking of the podcast. For sure I read every single one of them personally! Or, if you prefer a more direct contact, don't hesitate and drop me a note at feedback@embeddedsuccess.com The post Engineers’ talk: Internet of Things with Marcus Behrens – MES007 appeared first on Embedded Success.

What is a task-force? The term came into extensive use originally by the United States Navy around the beginning of 1941, as a way to increase operational flexibility. The fleet itself was divided into division and squadrons. A task force can be assembled using ships from different divisions and squadrons, without requiring a formal and permanent fleet reorganization, and can be easily dissolved following completion of the operational task Nowadays task-force is something different, no longer using the military speech: Small group of 4-12 persons With a specific set of skills Accomplished for a short term task Exits only for specific, time-limited purpose (few day until one year) Members often come from different parts of an organization A task-forces enhances enhances the project’s chance for success When to use a task-force? Task-forces are regularly established in project management when: Project confronted with complex or thorny issues Solutions require organizational change Involving different perspectives often greases the organizational wheels Task-forces are especially valuable if their outcome impacts people deeply or emotionally. Or impacts a large part of the organization. Why do task-forces stumble? Task-forces stumble mainly due to three different reasons: There is no task-force charter given and agreed Task-force members are not made to do the work Task-forces are too often established and therefore loose their crispiness and dedicated flavor Task-forces are the strongest kind of team In all the different approaches to do work with teams, the task-forces are the strongest way to proceed. You have great chances for rapid progress, you have best heads in the team, and good chance for successful outcome. However you also have to face the disadvantages that task-forces distract from regular work, consumes a lot of (company) energy, and it’s working across hierarchies might be taken as anarchic way of action Especially as in some organizations task-forces are established too often, their effectiveness gets lost quite soon as they become regular. The task-force charter The previously mentioned task-force charter should contain the following topics and need to be agreed by everybody engaged into the task-force: Purpose and objectives of the task-force Roles and responsibilities of the task-force Others involved into the task-force (project manages, top management, consultants, etc.) A list of tasks and expected work products Overall task-force timeline Resources which will be made available How-To successful task-force? My list of 5 tips to make your task-force successful: Tip #1 Stand Out Give you task-force a unique name that it is distinguishable from other ongoing activities. And stick with this name until the end. There’s nothing more worse than renaming the activities without real need. Tip #2 Start small Less is beautiful. Take as less persons as possible into the task-force, however as much as needed. Tip #3 Do operations on a schedule Give clear structure to your task-force members. These guys needs to concentrate on resolving the issues. A good structure gives them a solid harness they can concentrate on the essentials. Tip #4 Create and enforce rules It’s essential that agreed rules are also checked and enforced it they are not followed. Make this point clear in the agreement session. Therefore as less rules as better. Tip #5 Be a cheerful leader Laugh and have fun with the guys without loosing your focus on the goals of the task-force. This kind of relaxing and cheerful talk and appearance might decide whether your task-force sustains or gets lost in all day trouble. Outlook The next episodes within this mini-series about Task-Force‘ing Launching a task-force Running a task-force Doing the aftermath of a task-force If you already have your preferred solution how to prevent being trapped in such projects – let me know. I do appreciate all of your contributions. [saf feature=”email” cta=”Let me know your way”] Now I’d love to hear from you: What’s your experience with projects running into trouble? Do you have a warning sign that I didn’t listed here? Or do you wanna agree or disagree with me about these symptoms? Thank You For Listening Out of all the podcasts available in the Internet you tuned into mine, and I’m grateful for that. If you enjoyed the episode, please share it by using the social media buttons you see at the bottom of this note. Also, I would be very happy if you would consider taking the minute it takes to leave an honest review or rating for the podcast on iTunes or Stitcher. They’re extremely helpful when it comes to the ranking of the podcast. For sure I read every single one of them personally! Or, if you prefer a more direct contact, don't hesitate and drop me a note at feedback@embeddedsuccess.com The post 5 tips that your task-force gets successful – MES006 appeared first on Embedded Success.

Why does a project run into trouble? There are a lot of reasons why a project might run into trouble and most project problems are indicated by specific symptoms. Problems of projects are often caused by changes in leadership, company organization or the company itself. All of them create FUD – Fear, Uncertainty, Doubt. As a result we see inappropriate planning, schedule, staffing, and tons of other issues. The reasons for project trouble might be impacted by you or not. From the outside key signs are very often rather clear. But very often they cannot be detected from the inside. Within daily work-load, unaware of changes in environment or the company, with lots of rookies in place, critical symptoms are not recognized or misinterpreted. There are always warning signs – the flashing yellow light indicating that a red light will follow. This episode is about the key-symptoms I have detected during my career indicating that a project is in trouble. They do not mean that the project will fail, but they indicate that there’s something going wrong definitely. And they highlight that additional attention is needed – either to fix them or to escape them. This episode is about this very first step – the symptoms. What are the warning signs that your project is in trouble? I followed a variation of the Ishikawa-method to categorize the different symptoms. This gives us the opportunity to see the bigger picture. But it does not mean that the different symptoms could not be summarized under a different category. Process & Definitions Missing or shaky project direction Detectable by: Micro-management; Contradicting statements and direction advises; No direction at all – Silence Results in: Missing of scope and waste Company statements conflict with project goals Detectable by: Less attention by company leaders; Statements about withdrawal of the project; Denial of continuity in support Results in: Loss of reliability by customer; Drop down of credibility Absence of standards and methodology Detectable by: Different process actions for same situations; Constant introduction, withdrawal and re-introduction of tools, processes and methods Results in: Invention of processes and standards on-the-fly; Disturbance, frustration and intolerance; Decline of effectivity and efficiency Communication Bad communication within team Detectable by: Personal issues; Hidden conflicts; Unwillingness to speak with everybody Results in: Bad productivity; Frustration; Waste Ignoring expert’s voices Detected by: Expertness requested but not followed; Over simplification of problems Results in: Wrong way of realization; Wrong destination; Waste of effort due to inability to realize the wishful thinking Client becomes unresponsive Detectable by: Requests for information are not responded; There is no “No news is good news”; Critical decisions are made without client attention Results in: Sailing in foggy conditions; Silent drop by client; Withdrawal behind the scenes People The “vision guy” leaves Detectable by: No further technical lead guidance; Lack of response in general design questions Results in: Headless chicken mode; Management mess – who will be the successor; Re-planning/-building/-organizing, “Re-“whatsoever Everybody is the visionary person Detectable by: Everybody is barking a different tree; Changes are requested you have already requested long time ago; Team members fight about specs; Project is accounted by corrected faults, not by completed features Results in: Arbitrariness; Bewilderment; Inactivity No visionary guy at all Detectable by: Nobody cares for the project’s progress; Nobody is in charge; No report; No manager/leader; Project does not really matter – to anyone – besides you. Results in: Arbitrariness of project and result; Stopping of project the moment management gets aware of the situation Management Project goals less important than company politics Detected by: Management is fiddling into the project’s leaders/managers work; Micro-Management by company-leaders; Thwarted project goals by conflicting company goals; Zero-fault targets (see also Episode #4); Dislikes by Executives; Boss’s statements like: “I know best what the customer wants” Results in: Project members become puppets; Project goals are ignored or silently withdrawn; Nobody takes any risk; Communication with client will drop down Your project’s success is not defined Detected by: Senior management cannot describe the meaning and intention of your project; Stakeholders have different measurements for success; Client’s perspective not requested; Project targets are taken to a minimum level Results in: Wrong project outcome – customer frustration; Waste of effort for arbitrary goals; Frustration and demotivation Environment Too much overtime Detectable by: Constant overtime covering bad planning and bad scheduling; Weekend work becomes the regular working mode Results in: Bad morale; Bad mood; Attrition rate increases; Decline of productivity Shortage in money Detectable by: Travel bans; Mandatory investment is not made; Project schedule stretched; Reorganization of company ongoing Results in: Window-to-market missed; Investment failed; The end of the project Outlook How could you prevent to be trapped in such a project? How to overcome such projects? Why do you find yourself in such projects again and again? I want to follow up these questions in one of the following episodes. Stay tuned. If you already have your preferred solution how to prevent being trapped in such projects – let me know. I do appreciate all of your contributions. [saf feature=”email” cta=”Let me know your way”] Now I’d love to hear from you: What’s your experience with projects running into trouble? Do you have a warning sign that I didn’t listed here? Or do you wanna agree or disagree with me about these symptoms? I’d love to hear from you about what’s your detection and experience with project failing symptoms. Please comment here in the show notes and let me know what you think.   Thank You For Listening Out of all the podcasts available in the Internet you tuned into mine, and I’m grateful for that. If you enjoyed the episode, please share it by using the social media buttons you see at the bottom of this note. Also, I would be very happy if you would consider taking the minute it takes to leave an honest review or rating for the podcast on iTunes or Stitcher. They’re extremely helpful when it comes to the ranking of the podcast. For sure I read every single one of them personally! Or, if you prefer a more direct contact, don't hesitate and drop me a note at feedback@embeddedsuccess.com The post Have you these symptoms of project problems? – MES005 appeared first on Embedded Success.

What does it mean? Zero-faults strategy means that there are no faults accepted in the delivered product. Or at least only a very minimum amount of failures with low priority. Regular for medical devices, avionics, spaceflight. But is it really necessary for other industries? The zero fault phase might start anytime before the near customer delivery. Why are there zero-fault targets? Customer only wanted to accept mature products Too many faults in delivery product Customer complaints Symptoms and impacts with zero-fault target approach in use Wrong priorities due to priority inversion Artificial delay of deliveries Congestion of problems and tasks Complete usage of resources for low priorities Exhaustion, frustration and finally demotivation Notes about quality Quality cannot be tested into the product It is essential to know what the customer really wants Clear and precise goals and priorities from management for the different projects and programs. What can you do if you’re in a zero-fault phase? Leaders & Managers You can take the following actions in a short-run: Decide with customer what are the relevant features. Distinguish between: Must-Do, Should-do, and Can-Do. Concentrate on the Must-Do factors. Take care of mutual exclusive resources Renegotiate the deadline / renegotiate the system requirements or both Run the Triage! Details see Wikipedia And these are my proposed actions for the long-run: Understand the intention of the innovators of 0-fault target. What’s behind of it? Educate your engineers. Quality comes from know-how and this can be trained and learned. Read the book “Death March” by Edward Yourdon Get familiar with the big-tanker captain’s view Software-/Hardware engineers To mitigate or handle the effects of zero-fault targets you may take the following actions: Show and highlight your outstanding tasks and priorities Move the decision for priority and order of tasks to the managers Inform your managers in time about priority clashes and overload situations Read the book “Death March” by Edward Yourdon   Thank You For Listening Out of all the podcasts available in the Internet you tuned into mine, and I’m grateful for that. If you enjoyed the episode, please share it by using the social media buttons you see at the bottom of this note. Also, I would be very happy if you would consider taking the minute it takes to leave an honest review or rating for the podcast on iTunes or Stitcher. They’re extremely helpful when it comes to the ranking of the podcast. For sure I read every single one of them personally! Or, if you prefer a more direct contact, don't hesitate and drop me a note at feedback@embeddedsuccess.com The post Throw away your zero fault targets – MES004 appeared first on Embedded Success.