is the name of the team I have met today. A team composed by a 2 people who are analyzing a set of processes that they need to be improved in terms of efficiency and ability to absorb peaks.
The guys complained that all is in paper and that they were expecting data in a database or at least in an excel so they can analyze that.
I just broke out laughing: welcome to real life.
is the main fact these guys want to ignore. Yes, there are processes with legal papers that are scanned and managed, but legal communications are done by paper and we cannot change it.
This fact supposes a great wall that did not let them to see beyond. They just were paralyzed in front of this real fact.
“Come on guys, you have Six Sigma certifications, you share all these theory of Lean in LinkedIn, and now you come to me with this problem?”
Theory of constrains
is the basis of the history of the book The Goal (written by Eliyahu Goldratt), that simplifies the application of this theory in 5 steps.
I have commented them to go through this simple guidance and avoid a big bang approach to work on specific aspects. A big bang approach is not sustainable in a production line that cannot stop, this is a basic idea that they understand.
Finally I found that they perfectly understood the situation and my approach, the funny thing is that all they are asking is because their boss just want “data”.
I assisted to this Webinar presented by Gartner, and the more interesting part of the conversation was when the discussion was on this table:
One of the figures commented during the event was that 70% of the data the manufacturing companies have is not used. There is still so much progress in terms of metrics that can be done.
For descriptive, diagnostic and prescriptive metrics the companies have so much in place and the maturity is good. But in terms of predictive metrics, here in the same way that retail companies are already analyzing the behavior of the consumers, the manufacturing companies can still open the use of prediction to look for benefits in terms of quality, time response and quality.
On the survey done to 83 people from the sector, there was a question:
In which areas is your organization planning to drive business value from the use of manufacturing metrics currently and over the next two years?
The answer was:
The 4 areas that are in the minds of more people are:
- Capacity utilization.
- Understanding of true manufacturing costs.
- Faster and better decision making.
- Demand forecast accuracy.
The question that came to my mind was:
how can predictive metrics help to the business to improve these four areas?
- Capacity utilization: here predictive metrics can have an important impact.
- Understanding of true manufacturing costs: here what we have to analyze is the past, not the future. Diagnostic metrics are more useful.
- Faster and better decision making: here predictive metrics can have an important impact.
- Demand forecast accuracy: here again diagnostic metrics are more useful.
I have already worked with different customer frameworks, and the companies I worked, they also have their own.Everybody has one, and they all are more or less aligned with the standards: PMI, ITIL, Cobit, Togaf…
Every time I start with a new customer and I dig in the rules of the game (their framework), I ask some basic questions:
- Does it cover management or it also includes technical and architecture sides of the work?
- Has it templates? How good are these templates?
- Do they describe standard processes?
Is there supporting tools for working in alignment with the framework? For instance, on management processes, a EPMO environment enables the people to track and report about the different subjects of the project.
- And the last one: How mature is the utilization of the framework in the organization?
The answer to the last question is the more interesting to me, here is where you can see how committed is an organization in terms of governance and management of all the aspects of the IT activities in an organization.
Not all companies are committed and “married” with their frameworks, and the use demanded to the vendors is not always equal.
In an environment where different vendors are competing and you want to ensure the quality and coordination of the whole implementation of the IT activities, the exhaustive use of a framework is key to promote equal competition and avoid low quality.
This sounds basic, but I have seen this sequence so many times:
- In short term they accept cheap proposals assuming lower levels of quality in terms of documentation. In the short term, there is not high impact
- In medium term, when they want to offer new RFPs, they find the situation where the lack of documentation limits the number of providers to compete. The price increases and the quality decreases as in the next projects the lack of updated documentation extends all phases of the projects.
- Finally, in the long term, you can see how the company decides that it is better to pay to the vendor who has the knowledge to update the documentation, being this process more expensive than the individual update every time you change something.
In the improvement program I’ve worked, we have done a set of improvements and definition of processes for the different areas of the business we decided to work on.
Every aspect of each process has their details, and they also are linked with the others.
I created this chart to represent how they are going on in terms of evolution, try to discuss and prioritize next steps.
We could not put in place all the improvement actions at the same time as operations and business day to day do not stop, so we planned it in this way: launching each improving at different quarters and introducing others once the previous ones were matured enough.
In some areas we have advanced a lot, in some others we still have to improve, but in general the adoption of these standards have improved the efficiency of the operations and the understanding of “what the others are doing”.
Look into internet a report from Gartner and Cast Software named “How to Monetize Application Technical Debt”.
They expose a simplified formula for the measure on the individual of a given application based in the number of violations per thousands of lines of code (violations per KLOC).
The formula proposed for Technical Debt is:
- L = Number of Low-Severity Violations per KLOC
- M = Number of Medium-Severity Violations per KLOC
- H = Number of High-Severity Violations per KLOC
- S = Average Application Size (KLOC)
- C = Cost to Fix a Violation ($ per Hour)
T = Time to Fix a Violation (Number of Hours)
Technical Debt per Application = [(10% * L) + (20% * M) + (50% * H)] * C * T * S
They do not forget the business value as important element of the application value, and they add a conceptual graph where they visualize the application Technical Debt and the Business Value as a Function of Structural Quality Violations.
Maverick buying in the supply management arena is the purchasing outside of standard procurement processes, also known as off-contract buying.
The standard processes always tries to minimize this type of practices, because if an organization use it in an excessive way it has fatal consequences. But in some cases it is necessary to be flexible because you can face the situation where a remote location requires an urgent purchase to avoid to shut down its operation.
To try to recognize this practice, measure it, analyze it and understand the cases and volumes of Maverick buying your organization has, is something you should do.
The main reasons of buying off contract are: buyers prefer a local supplier, an item is required in a hurry, it is thought that you are saving money by purchasing a lower-priced item, or the buyer do not know there is a discount on the standard process.
There are two main types of structure for purchase departments:
- Centralized operating structure
: where all is executed from this organization and does not enable the participation of other specialized teams that can contribute on specific types of purchases.
- Center of excellence organization, that focuses on corporate sourcing strategy, and communications with all the procurement people.
Both have advantages and disadvantages with respect the Maverick buying practices.
For the customer I work, innovation is more related to an “improvement culture” than other thing. If the its IT environment is improving, they say we are doing daily innovation.
They believe that new ideas come from the work on the ground, people doing daily activities and thinking about how to improve the applications, some functionalities and speeding up details. There is a lot of value there and they appreciate it.
We have been talking about continuous improvement and how an incremental innovation is a valid parallel concept. It’s a pleasure to share ideas and concepts.
This exercise is so generic and just try to think a little bit about it. For sure it depends on so many variables: product, service, industry, target users…
Ok, let’s try it, where does customer satisfaction comes from? Mainly it comes from:
The relevance and the way it’s seen each one of these aspects is different.
First feedbacks usually comes from optics aspects. For the other 2 sometimes it takes more time to receive feedback (depends on product/service complexity).
For complex systems the results usually takes too long to be understood by the majority of the users.
For old services/products, that are typically working fine, provoking no noise and providing a good value, the results and the performance are much appreciated.
They feel these products/services as a part of themselves and no firelights are required.
Which Projects are more aligned to PM methodology? Infrastructure or Application projects?
During the check of the health of the projects we point to this alignment as another factor. With it, we have discovered that in general infrastructure projects follow the methodology in a better way than application projects.
Are the best PMs on infrastructure? No… Is there better background on infrastructure? Not either…
Observing how they work, we have seen how infrastructures work always following this cycle: they define the need, they look for a standard solution or product, they find it and check that meets the need and they implement it. This behaviour is something natural for them, they are used to look for the standard and they work in the same way on management.
On the other hand, applications background had in mind a bad practice: “…if I cannot find a solution I can open development environment and write the code for what I need…” This behaviour is transferred to management activities: all can be done on my way.
I can be wrong, but it’s what we are observing in our limited environment.