The Boeing 737 MAX 8 is a classic example of escalating quality costs.
You don't have to run the diesel gate any further. The disaster with the VW ID.3 is another one.
The "magic triangle" is time, quality, and the cost.
Some people believe that "agility" makes it better; experience does not support this theory until today.
The common starting point in almost every project today is:
The project manager duties often consist in the reduction of the development costs, especially the cost of quality. The subsequent costs of poor quality (poor development quality, Task Force Management, recalls, repairs, etc.), which are the result of the "development quality", often get ignored.
However, the project manager has all the tools in their hands so that he can reduce quality costs. Likewise, if it is not the first project in the environment, he can justify the actual costs factually.
I below go the study results of the PMI for project failure and pair it with the classic themes of project management. I will show where you will find the quality issues here, how to identify them, and how to ensure that you "stay on course".
You can view the standards, such as the Automotive SPICE ® PAM (Process Assessment Model) 3.1 or the Medical SPICE® (VDI 5702) as a "brake", or you can see it as condensed knowledge that can help you.
Often, due to internal constraints and external influences, it is not always possible to follow paths that one should take. I deliberately stay in the subjunctive here.
This standard can assist in developing an in-house process - standard.
The requirements by these standards processes, the base practices, and work products are also applicable if you use agile development!
I would be so happy to be able to tell you exactly that.
But things don't always go the way it would be best, even with us. We are as well struggling with the "inner resistance" in the companies. However, the following experiences and measures contribute significantly to increasing quality and reducing costs.
We cannot eliminate factual ignorance, "cross drivers" and "know-it-alls".
The following is, therefore, not only aimed at project managers but all project participants.
If these do not pull together, you as the project manager are at a lost post.
If you follow the points below, it will mean less money and more quality for everyone involved, even if it may not look like it at the beginning
We will take up many of these points below, show what the most common cause is, and what resources the project manager has at his disposal to control/correct these situations.
The following text is very simplified but describes it quite correctly.
The SPICE standard requests to develop software products that meet the customer's requirements. That is typical quality. And in fact, that's all the standard wants.
Almost every standard is written in such a way, that you search for the wastebasket if you arrived on page 3.
With a little effort, the standard becomes a MUST even for management.
Each process has a process goal.
Typically, all colleagues can be "brought on board" with this.
Each process includes goals, results, practices, and work products
(with quality criteria).
you must be able to demonstrate that in each process you achieve> 50% of the base practices and also that you create> 50% of the required work products.
the points above must be> 85%, and you must achieve planning and control> 50%.
everything above again at> 85% and a rollout to the branches with adjustment guidelines etc.
You will find that the base practice "MAN.3.BP5 resource procurement and rescheduling" can mitigate many problems.
And you need excellent processes for this.
But now to the points from the study and how you can "catch" them.
You are allowed to tailor the process!
First, the company chased and won an order. Now new orders arrive and other priorities rush in; the resources are withdrawn, to "solve" a task force, and thereby be the staff and sometimes even the funds are deducted from to "rescue" the other project.
The result is that those projects, who need to contribute to "solve the taskforce" now do not have enough personnel and or funds to complete the tasks, and the task force mode for those providing projects now are "planned", by the fact, that their schedule is affected.
The projects now generate a great deal of confusion as the concerned people often get into confusion about what their priorities are. Shifting priorities on a daily base is just adding to the confusion.
This is to be handled with: MAN.3 BP 5 get resources or rescheduling
Show that a person who works 1/3 each in a project does not deliver 1/3 performance.
Every new task always means switching. And before you get to do something, time passes. Resource sharing, assuming that time = performance, always goes wrong. Plan and show the consequences of the change. Fight for your resources. Nobody will like you, but “the like state” will reduce even more if you mess up the project.
If you don't have these resources, buy a team to do the work. Again, the new team needs time to be productive.
A customer of ours had already made massive mistakes in the planning, see also below "Inadequate resource forecast" and "Inaccurate estimate of the task time ".
The announced budget was 13 million.
Development costs/resources would not have been to master even with an experienced team.
The costs recalculated using a suitable method were 33 million.
This shocking announcement was ignored. It was not opportune.
And the number of staff was reduced despite evidence of already understaffed.
As a result, the company was two years in the Task Force mode, all of a sudden - because the customer, of course, at some point has threatened Project deduction - resources available.
The total cost exceeded 45 million
Proper planning means here: Management-appropriate and factually comprehensible. Factual reference.
The idea of solving everything with a standalone project management tool rarely works.
You must have life data from the individual processes and other projects.
If you are dependent on getting the data from the individual processes through regular "meetings and reporting", the data, apart from the inconsistency, is already out of date before you have finished writing the report. [Kovair can be of great support here, as it enabled you to keep in on a tool and synchronize all over the other artefacts of a project. Thus, you can do a transition as phase-in and phase-out, without a hard cut.]
A workflow management system is to be used here for digitization according to level 2 of SPICE according to the "GP 2.1.3 Monitor the performance of the process against the plans ". But here remember,
"A fool with a tool is still a fool "
Unsuitable tools, tools that are not linked, and tools that are not maintained in terms of content do not help you much, which brings us to the next point.
Estimates are often disputed. This disputing is understandable; when you see the pressure, you are exposed to—having to “win” the orders.
If there is a wrong method or no method to determine the effort, you have to estimate.
And nobody likes to spend money/resources
Optimism /pessimism in the estimation, as well as the dependence of the specifications from the sales increase pressure here. The Lessons Learned are often hidden, if executed at all.
The topic also quickly becomes "political".
An example is the BER (Berlin Airport), Stuttgart 21, or the VW ID.3
All of those Projects delivered beyond any time schedule, expensive and poor quality.
The causes mentioned for the project failure
are combined here with the above.
This is to be handled with: MAN.3.BP4: Define, monitor and adjust project activities and
MAN.3 BP5 get resources or rescheduling
Certificates are excellent, but do not replace experience!
The time that spent with one thing doesn’t make that experience!
"TLDR" = "Too Long Didn't Read" is often used as a justification for - did not do my job.
Something needs to be completed, so why/how can I spend my time with it.
The fact that there is no "completion" if neither read nor understood is "faded out" in these terms
Our client had a very experienced department head certified PMI.
However, missing: "the practical experience". (Certificate doesn't mean experience!)
Contrary to our, with facts and figures justified recommendation (tripling of resources required), or delay, the project was whipped forward and in terms of "the predecessor has said we are ready and only need the attestation" of the rollout enforced.
Our statements, although understandable, were "not opportune".
According to the above TLDR, the necessary standards were only read by an internal colleague and us. The internal project manager went to the border by stating: "I do not have to worry about the normative/legal requirements."
The result was that the rollout went "somehow", but several iterations of bug fixing were necessary afterwards.
And even after that, there was another "hilarious situation".
Even the most straightforward functions were suddenly very buggy.
Bug fixing suddenly accounts for 80% of working hours.
Management was still of the opinion that "we would only dramatize" and "nobody else does that" until the moment when the certification was not achieved four times in a row.
Total costs - including the increased certification costs - were eight times higher than initially planned.
A factor of 2 would have been enough if the whole thing had been processed correctly.
As already mentioned above, experience in the sense of "I learned it and successfully implemented it", or "I messed it up, repaired it and don't make this mistake again" here is the key.
If, as mentioned above, we are not believed, despite our experience, and we are on the project as external consultants, we know very well how you are doing as an employee.
The "controllers dominate many projects".
Sales examine the possible best offer that can be made.
Estimating costs is always a risky business because, on the one hand, you don't want to pay extra and on the other hand, you want to be able to offer customers a reliable product.
An agile approach may remedy this, but it is of no use if any of the stakeholders ignores facts.
If you do not pay attention here, you can produce considerable costs.
If you have
but you do it only on the functional level. You leave out essential information sources of your company, which ultimately also ensures that this project will not work.
In an orderly project process, the classic process situation is such, that one makes a cost estimate either
which then gives you an approximate indication of the costs you will incur.
Remember that the client also expects (even though he doesn't like) you to put a significant risk addon on your estimate due to a new project situation or any change scenario whatsoever and that you will come to him with an appropriate follow-up negotiation.
Also, you often probably do not always have the specialist staff to carry out this risk analysis correctly for you, and this only becomes apparent later in the project.
This is to be handled with: MAN.3 - the "Full process"
The Function Point Analysis is one of pure an appropriate method of software projects. For system development, it is not sufficient.
Every pilot of an aeroplane is obliged to do a calculation before take-off.
Condition of the aircraft, type of aircraft, loading, weather conditions, etc. and the necessary amount of fuel is calculated from this, including the alternative airfield (alternate) and waiting time (hold) for landing.
This can sometimes mean that the planned amount of fuel is up to 50% above the "ideal" situation.
In the meantime, this is often carried out by the "dispatchers" (comparable to the controllers in the company). But the pilot is responsible. Controllers without successful project management experience follow "pure teaching".
It is crucial for every person in the management levels from management to team leader that you trust your employees. If you believe your employee to bring the aircraft safely to your destination even in severe weather conditions, then you do not discredit your trust by assuming that he can not calculate correctly. A good pilot (and you are typically grateful to him) will refuse to take off if he knows that he cannot safely take off, fly or land the plane.
If you – as very often done – take the ideal situation, then cut down by "controllers" you wonder why you don't reach the destination?
We recommend the "Project Costs and Resource Estimation for System Development", which can be obtained here free of charge.
The initial effort to adapt the figures to the team carrying out the project (state of the team, project type, employees and know-how, risk ratios, etc.) is manageable with 2-5 working days after that cost estimates (prototype costs excluded) can be calculated correctly in about ½ day.
We are close to level 1
"Oh, great, then you have less task force now."
"No, we have more!"
"Some teams or project managers want to get higher on the career ladder. Therefore, you drive the project actively in Task Force mode, so that you can shine as "Hero" if you still bring it into series production.
You get a lot of attention and <<recommend>> yourself for the next level. "
In the actual example above, just about everything that can be wrong is wrong.
To work in such a situation as a manager/project manager is more like in a snake pit.
What are the typical root causes of insufficient or inadequate communication?
Better asked, how do you recognize this?
The topic "unwilling/unsuitable employees" is not considered in the following.
On the one hand, you can recognize poor communication by the fact that there are very, very many meetings in which you are continually trying to synchronize again and compare misinformation, on the other hand, there are e-mails, with the content like "you can send me the latest status again ".
Here we see that obviously, the information chains and storage systems with structures do not exist. Often there are not even tools that allow clear communication.
And right in front of them are deficient processes.
And in front of that are poor processes.
If you look at it straightforward, drawings or specifications are nothing more than communication elements in which requirements are communicated to a process participant in text or drawn form.
It only becomes more complicated when the content is not explicit.
You see, it is not so easy to do this here, but the elements described here are all an indication that bad communication can develop very quickly.
But what is worst of all is the lack of central storage and version management of requirements:
And how do I ensure through my change management that this information is always available and that I can give it to someone at any time, knowing that I am not giving out the wrong information?
From this poor communication and the idea that it won't be that bad, the next problem arises.
It has to be finished faster; we don't have time for that now, it's like a trip without taking the things you need in the destination area. Only the "today" is important.
At 39%, the incorrect/incorrect recording of the requirements is the crucial factor for project failure. The other way around can be derived from the failure side :
Proper requirements ensure successful projects
Requirements engineering for each process and the associated review seem to make the project very "slow ", especially if there are still deviations in discussion and need to be corrected.
In times of "agility", "DevOps" and "continuous delivery", as well as the idea that something should be completed every two or three weeks, the procedure "Requirements Engineering" seems very old-fashioned.
The time of 2 hours for one(1) request seems utopian slow, but in the automotive sector, it is rather fast. The creation of an architectural element is assumed to take about 20-25 working days.
If the requirements are bad, how can the product be good?
The 1987 statement
Software Defect Reduction Top 10 List
"Finding and fixing a software problem after delivery is often 100 times more expensive than finding and fixing it during the requirements and design phase."
is still valid today.
The risk at the same time, which means 100 x higher costs and lower quality unfortunate people turn poor quality and slower work are things that you should avoid if at all possible.
To be handled with: Processes SYS.- and SWE.1-3 in combination with proper planning
The requirements of a project are the basis for planning and change.
This is a truism that is often not seen in this light.
If we look at a typical development in automotive engineering, we always have four sample stages.
If you have poorly planned at the beginning and the requirements are not precise, you have to be aware that you have to prepare for a complete failure.
You must take this risk into account.
The potential effects:
A colleague from the mechanic's department was given the task of evaluating a "new specification" by the customer. Although not at all established in the company and ridiculed by everyone, he took our advice to heart, transferred the document into a requirements engineering tool, and evaluated each requirement and coordinated it with the specialist departments.
Subject logic beats any opinion here and - if it has been made in detail, this work of the supplier increases the relationship of trust - and that is almost priceless.
Use your toolchain, which keeps the information consistent, or introduces one and make sure that you use the tool.
There is a tendency to go back to file storage systems because these "new" tools are powerful and therefore require training and a certain amount of work discipline.
(And the tendency is not to have more discipline)
Make sure that they have this single point of information at all times and thus have secure information. It is also imperative that you introduce active monitoring. Use the normatively required review of the work content, i.e. a so-called review, which ensures that the work content, which currently represents the so-called latest status, still corresponds to the customer's requirements. This has an exquisite side effect because this way, you can quickly introduce the so-called continuous improvement process because you always check the work content. You will realize relatively quickly that the employees find it very good to know when something is right and when not.
"We finally need a real code review " was the statement of the employees in the project.
If you work effectively here and check the progress, you also prevent that
40-50% of every (software) project is avoidable rework. This has also been known for years.
The above requirement management with review will save you tons of extra work.
Besides, there is often a faulty monitoring / wrong tools/ignorance.
"Who measures a lot, measures manure" is a German phrase. Typically, the progress of the tasks is checked and the degree of achievement "interrogated".
However, an excellent tool allows you to check not only the status of the tasks but also the status of the associated artefacts. A status model for the requirements, the associated practice of planning each requirement for the releases across the process levels creates transparency here.
Over time, it has crept into companies that it is better to deliver the wrong data, declare work in progress as finished, and report the project status "beautiful".
Projects that are in the "deep dark red" status are still reported as "yellow" to avoid stress with the management.
This requires your instinct. There may be a real fight.
"Experienced supervisors" who have swept the problems under the carpet for years are of course mercilessly exposed in tool-driven reporting.
Resistance to tool usage is preprogrammed.
Management support is imperative.
Overload also arises when people are assigned to several projects.
Every project manager needs the vital resources a hundred per cent. 50% are promised, and then the resources and employees are still assigned to 3 projects.
It is evident that with tools, you have to accept the set-up time. The fact that an employee has to "switch heads" three times as many meetings and votes with 30% project availability, and that this 30% is then de facto only 15-20%, is often not considered. 400% planned workload, I have experienced. The project situation, the atmosphere, and the quality were accordingly.
To be handled with: MAN.3.BP5: Define, monitor and adjust project estimates and resources
Proper tools show you the cross-project resource usage. But the best reporting and monitoring is useless if you work correctly in planning (see above).
Of course, the overload is also caused by the just mentioned
In a few areas, there are indeed limited resources and a dependence on "only one supplier/employee".
The crux of the matter is that while you try to qualify another supplier and reduce the dependency in every supplier relationship, with employees, you tend to burden them beyond all reason. Likewise, the ability is not seen in one's own company.
A colleague who worked as an algorithmic on the "lowest level of V" was proposed by us for the position of system requirements analyst. This caused great surprise to the head of the department and the human resources department.
After a conversation, one was "baff surprised" to have such an employee in the company.
The colleague was then within a short time, the "Function Owner" of about 80% of all functions on the system level. It was "imposed on him to work" that he should have worked at approx.—180 %. Only the repeated intervention to give the colleague air to breathe and to support him with other employees led to the load being reduced to a tolerable level.
This dependency on a "single resource" is solved in most cases
At least one hour a day for training/education.
Although you have an hour less time to do the job, this hour usually results in more efficiency or higher quality.
To be handled with: MAN.3.BP6: Ensure the necessary skills, knowledge, and experience.
Part of the project manager's tasks is as above. This implies that, in addition to the training mentioned above, you also plan to improve the skills required by the executing staff.
While training is usually a measure initiated by the HR or quality department, you add project-specific training. Each knowledge gained leads to a happier and therefore more efficient person, and a happy and cheerful staff is exactly what you need.
And when you do that, the reactions are something like that.
" To my astonishment, all of the goals planned for six months were achieved within only about four weeks by the entire team.
After that, the tasks have been significantly expanded (multiplied) ..... .
Here the task was to master the technical details of each error to be classified within the modules to systematize and so prepare, that the error solution for was as simple as possible to implement the SW engineer.
While Mr X himself acquired detailed knowledge about the individual modules within a very short time, so that he was always a technically competent contact person even for the specialized employees (who received up to 4 hours of training daily), he made sure in parallel that the knowledge was transferred into a systematized form and that a knowledge transfer could take place in the team. Despite the daily increasing workload and demands on the team, this systematization and concentration on the necessary processes have led to the fact that the analysis team has always achieved the specified goals.
The argument that not much productivity can be created through training, thus falls away.
Skills and understanding provide for more efficiency, and that permanently.
Another challenge is that the customer expects his timeline to be met. Starting with the above planning and reading the requirements, the first levers to avoid these stress factors are If you show the customer solutions to meet their main schedule, they will play along in case of delays, as long as you deliver decent quality.
The customer, to whom you deliver a product that does not meet his requirements, makes you very unhappy.
That suppliers deliver all kinds of things, just to say that we have met the delivery date, we have not only experienced this once. (On customers and suppliers' side).
But meeting the delivery time is only ONE requirement
I don't need to describe the resulting emotions and the basis of trust.
You have to do the "bad" work again, but now, due to the advanced stage, you don't have time for that anymore, because otherwise, the next stage will be even harder to reach.
In other words, the supposed solution becomes a problem because the workload has increased, and the schedule has remained the same.
Once you have established with the client that you are reliable, the client will fight for you like a lion.
All processes on the left side of the V. (SYS. & SWE. 1-3) are requirements!
With honest planning, open communication and excellent quality (== Compliance with Requirements), you convince the customer and also your colleagues internally!
processes and new development together:
You have a war on two fronts on the project.
On the one hand, you don't know what to do, and on the other hand, you don't know how to do it. In such a case, make sure that you have at least one process expert with you who is involved in developing the processes during the development phase and who acts as a contact person for the development team, thus eliminating possible weak points in the project from the outset.
And as already mentioned above - project manager without experience ... These then take care of the next point:
Any risk that is recognized late reduces the likelihood that you can get it under control and "increases blood pressure". It becomes hectic, and the resources go into the overload mentioned above.
Either you identify and control the project risks
or the risks will control you.
One of the fundamental problems of a person is that the person believes something.
Belief is: "Knowledge independent of evidence."
To put it more profanely, I could say that I think the requirements are OK, I believe that the lights are off in the basement, I think I have locked the car.
The difficulty of people is to apply knowledge and to know that something is right. A similar problem is the famous saying: "Out of sight, out of mind" or "What I don't know doesn't make me hot".
Proper planning includes considering the risks.
The first step in reducing risk is to read the customer requirement specification and other applicable documents and reflect the customer "I agree/disagree".
((One) 1 requirement document of 120 pages contains 20 pages of "Applicable documents
At the very beginning of the unread preface – The Idea: you only need to read the requirements and understanding of those is not mentioned at all - is the sentence:
"All the above documents named are legally binding and valid."
20 pages with about 30 referenced documents each ± 50 pages /document and further cross-references if necessary.
At the latest here it pays off to read the specifications correctly and to reject this point at the beginning.
Use checklists like in aviation or train the "pilot" regularly in the simulator. Challenge him with risks that you know you might have.
These simulator flights for pilots keep combining situations that, in ordinary life, you will never meet.
If you are trained and aware of risks, you have a certain alarm status and will act early to avoid a crash.
Whenever risks have not been actively addressed, or are ignored with the
the resulting problems have become all the worse.
Even after the risks have turned into problems, they are often not accepted because the view set never switched from "I believe" to "I look".
Don't take risk management as if it is not going to happen.
In functional safety (ISO 26262), there is the approach of the intolerable range, which must be shifted into a tolerable range through suitable measures. This means that the status of the respective risk processing must be consistently checked here, just like the pilot who regularly checks that all parameters of the flight and the aircraft still fit. It may happen to you that you get different chances and risks when flying around the thunderstorm.
Each pilot has suitable tools, weather radar, weather observation (from other pilots and the Meteorological Service) maps, satellite information and, and, and.
Do you have this data and the tools too? Do you have the "display tools" that will show you the problems?
With all your risks, pay attention to the "magic triangle", the connection of quality to cost to time.
At first, it was a small representation of static information to be later a game for 16-year-old.
Although this is not as blatant in the automotive environment as it is in other projects, it is gladly tried again and again. "The only constant: Changes”.
It is precisely under these conditions that every project is located. At the beginning of your analysis you might come up with a budget of 10 million €, after some time you will find out that due to new, e.g. product liability requirements, the previous assumption is torn or has been torn. Your goal to realize the project at time X is no longer realistic under the current conditions.
As soon as you realize this, the project has to be escalated. Even if the typical reaction is "It won't be that bad." The answer is: "Yep, it'll get worse".
So far, we have never seen it "not that bad". It is also the job of the project manager to ensure that the resulting risks and changes are fully considered.
The brushoff: "It won't be that bad" is only brought up by those who are not in the project.
The right answer: look, rate, PDCA
To be handled with: MAN.3.BP4: Define, monitor and adjust project activities. and
SUP.10 Change Management
Because the customer's requirements change, the goals, including the milestones, have to be constantly readjusted.
Start again with the above requirements!
As soon as you receive the changes, rate them with a CIA == "Change Impact Analysis".
A "big change" turns out to be relatively easy to implement, a "small change" can mean that you have to set up the entire architecture of your system again.
The risk assessment needs to be revised.
This also applies to the so-called "make or buy" decision. In other words: "Do I buy the potentially critical service now or do I continue to develop it myself with all the other risks that may still be latent in the previous requirements.
With all estimates and assumptions, state why something you use is what it is.
You may have the experience, have you asked someone, or you have a method used to the somewhat dissipate.
Assumptions and limitations and methods may change, and therefore a change is for each easier to understand item when you and the others know, how did you come to the result.
It is best to create a checklist or method that can be used in your company.
is depending on the vision or objective for the Project several estimation methods have their absolute authority depending on the scope of the function.
Just start, it's so easy. Then, as soon as you get the first results, everything changes. The requirements - see above - are unclear. Interestingly enough, even experienced project managers often find it difficult to define the project scope. But it is probably relatively easy for an outsider to see what the company or project is supposed to do. It is not so much a matter of describing the scope of work in a highly academic or stylish way, but rather of capturing the current state or scope of the entire field of work.
To be handled with: MAN.3 BP1 Define the scope of work.
From a development point of view, these requirement descriptions of the project scope are often a rather tedious task, but from a resource point of view, this makes much more sense. How do you want to convey what you are doing in a project if you can't even describe it yourself?
Example: a control unit for an alarm in the car.
You can now simply name the control unit for the alarm, or you can consider it as new development or a further development so only these two names. Still, unfortunately the reader then no longer knows what it is all about and what the time horizon might be. This is called "Sense of Urgency". To mean how important it is to you. The internal communication will then immediately shoot itself on this rather sloppy description and finally work the same way. Always pay attention to their effect on the words.
The scope of work represents a general presentation of the goal. Returning to the example, for example, an entirely feasible approach would have to be written:
We are developing a control unit for an alarm system that is to ensure that the end of the year implements 100 % of the functions based on Automotive SPICE PAM 3.1. The advantage of this notation is that it contains at least two dimensions in its text, namely a quantity reference and a time reference and thus also roughly describes the corresponding scope. Of course, you can give the project a short sounding name but this way you can easily communicate what you want to do in the project and when you want to finish it. The refinement of these activities then takes place in the strategy.
Planning and resources (see above) are again the decisive factors here.
Projects that "just start with" do it yourself "are to be rejected from an entrepreneurial point of view.
Projects with an unclear definition of the scope of work must be rejected. The amount of work that someone invests in the creation of a project profile and a rough plan is significantly less, that is, the "burned-up project that is dwindling away
The practices are purely in the project management process
which are direct with the project manager, the biggest chunks if you take this study as a benchmark.
The ADJUST so adapting to the facts is the area that is the most difficult.
A Fool with a Tool
Project management is not about drawing beautiful diagrams and graphics to be presented to stakeholders/management. Also, there is a problem not in it to use complicated tools and can be celebrated for its ability.
The point is :
"Align a group of people to a goal and make them work as a team."
No tool will help you if you don't have the skills to bring the processes and methods to life. So, if someone rushes to you and tells you that they have found the tool that will solve your problems, be aware of it. "A fool with a tool is still a fool."
When new methods and processes are introduced to the market, the "consultants and experts" who implement these methods and processes tend to forget the known and established foundations of success.
The right action when new methods and processes are introduced is to test them according to a process improvement process (PIM.3) and implement them in a Pilot project. If they are proven to be successful you roll them out or you discard them if they are not.
Do not forget the step "discard it", even if it is the boss' hobby.
When initiating a new project, study this list of good practices to determine which of them can make valuable contributions to the project. Study the causes of failures and make sure they don't happen again.
Norms/standards such as ISO or IEEE contain condensed knowledge. Therefore, we strongly recommend regular training. Incorporate the relevant activities into your considerations and plans.
No pilot of an Airbus will change the approach procedures for his large aircraft because someone can do great things with a hang glider or helicopter. Use methods that suit your company.
At the end of all Processes, there is a review. A review is a quality measure, testing as well.
People tend to plan, provided everything that has evolved is fine. Not all tests "pass". Based on the experience in your company, a certain number of errors and the time required for the correction should be planned. In security-related matters, a failed test can be a blocker. To execute these loop times after each quality-related action. (Review, analysis, etc.) Companies typically require planning for the best, most realistic, and worst-case scenario, assuming the best case always occurs. If you have experience in the company, you can predict the resource requirements for a similar product. Be aware that any project you undertake in an "unknown area" carries risks you have never thought about and challenges you have never seen before. Plan your buffers.
Write down the estimated and the actual values, as well as the reference system with which you determined these values.
To improve for the future, you should document the time and resources required for a task and encourage employees to document the effort within the framework of the legal requirements.
No plan survives the first contact with reality. Things happen - changes happen, and you have a plan that is out of date as soon as you start. Consider risks and their impacts to derive a buffer for the unexpected.
If all s is equally important, you cannot work. So prioritize! Create your criteria for the priorities
As a pilot, you wouldn't start if you didn't have enough fuel onboard, and you wouldn't choose a jet if you needed a helicopter and vice versa. Take the view of a responsible pilot and act accordingly. Don't start if you know that one of the following points is not aligned.
To the extent that you are uncertain about these goals, you inherit risk.
Again, the views of a pilot.
· What happens if we do not land on the desired airport (target)?
· Can you deviate from the plan if a thunderstorm gets in your way?
· Can you reorganize planned goals if a situation arises?
· What is "MUST"?
· What are "I don't want to have"?
· What is "nice to have"?
· What are trivial goals?
Note that all of these actions are not "set in stone" and can change. If they change too often, adjust to the needs of the stakeholders.
Typically, this is not seen as the primary responsibility of the project manager.
However, the topic is precisely the area that ensures that one can plan sensibly at all.
Automotive SPICE® gives you a list of 128 work products to be delivered and 122 base practices to be followed, ISO 26262 gives you another 120 work products. The total number of quality criteria for these work products exceeds 1000. And "on TOP" comes the "maturity levels".
The worst thing is that the product has not yet been created, that is only the "frame".
It's damn hard to convey.
But, since many of the artefacts can be grouped in a "container" (object of the same class) in the company, there are considerably fewer artefacts. And you can also take a relaxed look at the quality criteria (a payroll has > 30 criteria, so 1000 are not that bad.
The SPICE and ISO 26262 standards are condensed knowledge. The SPICE and ISO 26262 standards are summarized experience.
Create a list of ALL artefacts in the standard and a list of coherence - that is hard work.
Track the status according to the processes of SUP.8 "Report Status
This is then giving you the life data that are used for monitoring and any Status Report.
The best you can get – and at the same time you are on the route for compliance to the standard.
 Why Do So Many Managers Forget They're Human Beings?
 Heraclitus 2500 BC
[i] See also "Hype driven Development" https://blog.daftcode.pl/hype-driven-development-3469fc2e9b22
[ii] An example would be the PIM.3 Process Improvement Process of the Automotive SPICE ©
[iii] Templates that are in a tool and have specified "150%" or more are helpful here.
Deleting what you don't need is better than forgetting just one.