The Sorcerer’s Apprentice

Wise OwlWhen I received the Invitation for Member Articles email, my first thoughts were “what a nice idea” and “how many interesting experiences we’ll be able to learn from”.  Moments later, when I read  “…send us your true Project Management tales or book reviews. All topics are welcomed …” I got butterflies in my stomach. The word “tales” opened a magic door and let out lots of memories, experiences and emotions that were deep inside the PMP® I am today. Something transported me to early in my career (my professional childhood), when I was an apprentice who dreamed of becoming a sorcerer.

As perhaps some of you have also experienced, project management is sometimes a lonely role. Yes, you are part of a team and you get along very well with your team. But the weight of the responsibility, the fact that you must be the positive one when things become not so positive, the fact that you must keep everyone focused and motivated, all these make you feel a bit of solitude sometimes. Belonging to this PMI ISCoP community, learning from other people’s experiences, knowledge and concerns has made me feel accompanied. That’s why I feel comfortable and willing to participate with a bit of my own “project management tale”. Not a big deal, just a little story of two experiences in Project Management, first as a team member and later when by mysteries (or magic) of life I had to manage a project.

The last and the least

Almost twenty-five years ago I finished my college studies. I was very lucky when only a few months later I was hired into a very important multinational company in the technology manufacturing industry. I came in as member of the IS Department. In another few months I was put in charge of a small software development task in a production line and was moved into a new Production Support Department.

At that time, the Company was conducting a huge international project sited in another European country. Employees with experience in developing applications for production lines from many different countries were assigned to be part of the team.

I was assigned by my country. Most of the team members were senior software designers and analysts, with great experience in the subject matter. I’m still wondering why I was sent and I guess that I was the choice with the least impact on the operational work in my company.

So, I was the last to arrive, the youngest one and the least experienced by far. I was almost transparent in that team. I could feel the lightness of being not significant; experiencing how people talked, criticized and discussed without any caution when I was around, as though I was invisible.

In a situation like that if you are eager to learn, eager to deserve participation and are a good listener and observer, you can learn a lot.

The team was a clear pyramid: software designers (employees) at the top, developers (sub-contracted people) in the middle, and testers (sub-contracted and employees) at the bottom. I was in the test team. Project Manager? I don’t think there was one, at least not with that title. The team was structured the same as any other functional area in the company and we had a Functional Manager.

I was in a situation where I had to figure out the details of what exactly the project had to achieve and of what exactly I was expected to do. I never saw and talked with a user, or someone with a functional or operational role.

Asking was a sign of weakness and I learned to ask and talk to the appropriate people, the “not-so-busy” ones. Before I asked my questions I’d apologize for my ignorance, until I met a designer who taught me a great lesson: “the only stupid question is the one that is not asked”. This little sentence was the root of quite a change in me as team member.

All this helped me cultivate a quite fine sense of identifying the people who could provide valuable information and the ones that wouldn’t.

I learned from many of the great professionals, and from the not so great, from the committed people and from the not so committed. I did not judge, I just observed the actions, behaviors and learned from results and consequences.

I learned what a “prima donna” is and how things are when you have several “prima donnas” together. I saw people complaining all the time, and experienced meetings with endless philosophical discussions that didn’t allow me to know what was next and what we had already done.

I learned how people who seemed to be great experts could fail working in a team and make other people fail. I learned to avoid prejudgments regarding a person’s skills.

By the time my assignment completed, I knew about procedures, documentation, inspections, testing and what a Configuration System was and why it was necessary.

I also knew the experience of having a top project leader replaced by another one and how things changed… or not.

People had to leave the project when their assignment period was over, not when their tasks were finished. New members had to cross the desert of the integration into the project work and team. I experienced what a learning curve is and its impact.

I went back home before the project finished but having learned a lot about production lines, methodology and professional behaviors in IS teams. And how a member should never feel in a team.

Several years later, this project was canceled without achieving the initial objective. I personally would classify it as a failed project, but for my professional career it was the most important one. I learned a lot — mainly what a project is, how necessary project management is and what does not work in a project. From my current perspective I acknowledge that learning as priceless.

The issue and the project

Back at home,  an issue in a production line arose. This became in a notorious issue because it was a little black stain in the white and serious Quality Policy and Commitment of the company.

It was a long-standing problem, difficult to solve because the entire production chain was involved. It was a very difficult cat to bell but something had to be done to fix it; the Company Manager demanded it. Who was going to be the person to put on that bell? An expert analyst in the IS Department, or an expert engineer in the Production Support Department? Not exactly.  Management chose a person that had just arrived from an assignment and had no specific task assigned. This person had been working in a famous project to develop production line control software and came back with an excellent performance appraisal.

Yes, I was assigned to fix this issue. It was generally considered a bad assignment with an impossible objective, a task that would never advance anyone’s career. I considered it a great award though, my great opportunity.  I was going to be responsible for delivering a software tool to avoid more issues like that. I wanted to accept the challenge to demonstrate and develop my capabilities.

A project team

Having felt the experience of being directionless, I was going to put all my effort into avoiding such a situation. I wanted to have my job under control and to know exactly what I had to do.

I had no authority, no power and no resources but I had something very important that would be my “magic wand”: My Company top manager wanted that issue fixed, so I had to be paid a bit of attention.

First of all, I got my sponsor. I figured out who was the person that was going to be interested in the project, who was going to support it and me, the one to whom I would primarily report. I needed a Production Line manager and I chose the one who asked my manager for support. He was willing to participate as a sponsor, as long as I did not disturb him much.

Secondly I started a process of understanding exactly the issue, the environment or scenario and the most important thing, the people. Stakeholders? Yes, exactly. I needed to know the people who could help me understand the issue and its origin. I also needed to know who was going to be affected positively and negatively, what they thought about it and how they felt about it.

Then I wrote a document to describe what the issue was and what was going to be done to fix it. Also I specifically wrote what this project was not going to deal with. The project scope was clearly established, the team of users and stakeholders was also pointed out.

This document was distributed to my sponsor and second line management for approval. I just got an ‘OK’ but it was more than enough.

Little by little with the maximum respect, without judging, without blaming, recognizing who had the knowledge of the situation, I developed a nice team of users from the production line and other stakeholders directly and indirectly affected by the project. I knew how none of them should feel as team member.

With some of them I talked individually, with others in very effective meetings. Every stakeholder was different and I tried to be as respectful as possible. I wanted them to feel as I felt: we were a team working in something big, really important.

As an example, I remember I taught one of them how to use a computer mouse. I put a computer in a hidden area of the production floor and taught him. He was a foreman and was afraid of losing his position if he was not able to administer the new tool. He became a great supporter.

So, with all the requirements collected, documented, discussed and approved we knew and agreed what to do; now it had to be done. I needed technical team members but I had no resource assigned. And the IS Department schedules showed no developers available to be assigned to my project for the next several years.

Studying all my possibilities and resources available, I decided who were the people I wanted to work with, and went to get them:

  • An IS Department person. He had the experience and the possibility of getting resources through University collaboration.  He also was likely to be put in charge of ongoing maintenance and future development, once the project was operational.
  • Two Production Support colleagues of mine with huge experience developing tools for the production line and very highly-regarded by the users.

Their condition to participate was to dedicate to the project the minimum possible time. That’s what we did and I must say that their commitment to the project was complete although the participation was part time.

With my past experience always in mind and the team members’ experience, we identified the main risks, planned the responses and defined a change management system. Little by little everything was flowing naturally.

Finally deliverables started to be released and were ready to be tested. The usability and quality of the tool were critical to getting user approval and satisfaction. Test was not simply another step in the procedure, it was critical.  As much as any other task in the project, it was considered a vital element. There was not a hierarchy of tasks, everyone was important.

We were a very cohesive team, we really enjoyed those meetings to define what to do and how to do it. They were intense, and extremely focused. We always knew where we were and what was next. It was nice to observe how little by little people wanted to collaborate and be part of that team. It was great working all together.

I was very happy with the team and wanted to give them back all their support and collaboration. I wanted public recognition for them, especially since that was the only thing I could give them as a reward.

There were two major concerns that I considered as risks for the project success:

  1. Users might not properly maintain the tool and little by little it would die and not be used.
  2. No recognition of the team’s titanic effort in a project like that. No visibility or impact in their careers.

We planned a response for each one of these risks:

  1. Start using the tool with a new product. In this way, to produce it the tool necessarily had to be used and eventually the tool would be adapted and used with other production lines.
  2. Apply for an award and earn it.

The first response was a success that really worked. Our tool became critical for the performance of that production line.

About the second one, the award, I was told that a software tool had never gotten a quality award in our company, so the team was not very enthusiastic or optimistic. But they already believed in the power of determination. Guess what? Yes, we got the award, a national one. The whole team was publicly recognized with photos on the walls, economic rewards and great performance appraisals. We all were very happy with our successful and famous project.

Yes, this was like a fairy tale with a happy end. I experienced that there are moments in life when you feel insignificant and mistreated, but if you take the best of it, learn from the good and from the bad and grab the opportunities, things will work out.

I also learned that although many of the techniques and “spells” you need are already invented and you can study them in books, there is nothing like experiencing them, even if it is painful.  Squeeze every bit of learning out of your apprentice periods in life, do not avoid them. And keep being confident and enthusiastic. Someday you will be offered the chance to become a Sorcerer and you will be ready to undertake it.

(Author note: Thanks to Carol Brumwell who proofread this article.)