First some background about me: I work two part-time jobs, Mondays and Tuesdays I'm an engineer, Wednesday through to Friday I'm a draftee, although at the moment I'm doing some excel/multiframe programming/engineering analysis design.
The situation at my engineering company is this: foreign company required by government contract to provide certain percentage of work in country. That's us. Effectively our client is the government, and we represent the foreign company. Most of our (maintenance, very important point) work uses a streamlined process, where there is the minimum legal amount of oversight on the work that we provide in order to improve the overall efficiency / effectiveness/ turn-around time; and that is the work that I have been mostly doing for the past year or so. However, recently I was tasked with a modification instead of maintenance.
My manager decided to step with me through how our company handles on-going multi-week projects (most of my projects are expected to be completed within a week). I estimated about 60 hours to complete (about 4 weeks). He laughed. After going through the project times with admin, checking, writing, drafting, etc. I came up with 144 hours (about 10 weeks) which includes a 10% risk (I like to think of this as a training allowance). Now compared with my previous 15 hour project turn-around time I felt this was hideously over budgeted. As it was, the project ended up around the 135 hour mark, smack bang in the middle of the risk margin.
So how was I so very wrong in my estimation for the budgeting?
My first 'proper' job was doing similar kind of engineering but for the commercial sector. The turn-around times and budgets are much tighter than for government work. Also, access to OEM data is restricted. As a result, a higher level of engineering risk is accepted and use of engineering judgement was favoured (and often was the only engineering justification). My boss at the time was an engineer of about 35 years experience, running his own business (there were only two of us; I think the peak employment for his company was four employees). On occasion, I would not be able to understand why a particular solution was acceptable, to which he would reply that "based on my experience and knowledge - it will be okay".
This annoyed me.
I rebelled by making forms. And checklists. And cheat sheets. I even started on a manual. Of course I was trying to systematise the process for the engineering we were doing; trying to capture the skills and abilities of my boss, by without having to go through the time taken to gain that experience. This strategy is not uncommon. Although there was resistance to this, some forms later proved useful in the form of third-party audits. One thing I was not able to solve was the "don't know what you don't know" problem.
As an aside, it seems to me that the solution the pro-systems camp adopt is one of oversight, review and approval. However, at a proto-level, oversight, review and approval is still being performed by people; and so you are still vulnerable to the "you don't know what you don't know" problem. The systems' solution is, of course, to add oversight, review and approval to the people doing the overseeing, reviewing and approving...
Adding these meta-levels of process to a problem at the proto-level can only ever dilute the problem, not eliminate it.
The authority (e.g. Civil Aviation Safety Autority) has the problem of how much authority to delegate, to little and the delegation has no purpose. Too much and delegatee is vulnerable to the Dunning-Kruger effect. Myself, I go for the personal education and training as a defense to this.
Now my draftee work has had problems with their quality. Jobs have gone out that are straight out unfixable. This has meant massive back charge to us. Recently, our manager was promoted across the country, and our final checker was promoted into his position. What this has meant is that the new final checkers were now checking work for which they were not skilled enough to do. In addition the only training is on-the-job training. The person most recently able to be productive is tasked with the training new hires (an effort to solidify the training of the productive person). Any problems or questions are forwarded to one of the more senior draftees for resolution. What this has bought about is draftees who have been taught to obey the instructions of the engineers and engineers who have not been trained to an adequate level.
Another symptom is the sudden push at the end of every month to get jobs out. Ideally, there should be no push for jobs out as the budget should be comfortably passed near the end of the month with no change of pace. But there is: so what does that mean?
We now have three situations in mind. The first is my preference to for systems when first starting out. The second is a poor estimate of project time budget. And the third is the significant drop in quality of the drafting work. To provide a paradigm on which to analyse this I adopt the Dreyfus Model of Skills Aquisition. This model sets out 5 levels at which a person's skill can be categorised. Quoting Wikipedia:
- Novice:
- "rigid adherence to taught rules or plans"
- no exercise of "discretionary judgment"
- Advanced beginner
- limited "situational perception"
- all aspects of work treated separately with equal importance
- Competent
- "coping with crowdedness" (multiple activities, accumulation of information)
- some perception of actions in relation to goals
- deliberate planning
- formulates routines
- Proficient
- holistic view of situation
- prioritizes importance of aspects
- "perceives deviations from the normal pattern"
- employs maxims for guidance, with meanings that adapt to the situation at hand
- Expert
- transcends reliance on rules, guidelines, and maxims
- "intuitive grasp of situations based on deep, tacit understanding"
- has "vision of what is possible"
- uses "analytical approaches" in new situations or in case of problem
In the second situation, I feel I am about the level of advanced beginner / competent. For maintenance projects. What happened was that I based initial estimate.
So what does all this have to with the title? I propose that the system for technical jobs be flexible enough to accommodate the people who are working on it. In the specific example of the my modification project, if I had recognised that my level of skills was closer to novice than to competent, I spend some time with the manager to create some forms and checklists to go through job.
On checklists: The effectiveness of a checklist is equal to the comprehensiveness of the checklist multiplied by the probability that it is used. There is a tendency at my drafting job to fix problems with jobs by adding more items to the checklist. What this results in is a checklist that is 80% not applicable. However, hidden in amongst the "n/a" is a checklist item required that gets overlooked. Or you 'check' the same way that you do create, in which case a mistake is 'checked' OK. You can't check your own work, especially if you've just finished. I'm always surprised at the number of mistakes that sneak in overnight.
TLDR; Customise checklists based on the job and the person doing it.
No comments:
Post a Comment