Friday, April 29, 2011

Project Management Organization Style

I am occasionally asked about the differences between being a PM and being a TD. There is a large difference that I usually don’t discuss, but that it important.
In a traditional TD position, the ATD, Forman, and crew are either directly hired by the TD, or are hired with input from the TD, and report to the TD as their direct supervisor. Even in a scene shop were multiple shows are being built at the same time, the TD balances the load between the shows needs and the staff directly. It depends on the theatre if the TD also controls paints or props, etc, or if that falls to the production manager, but it is a fairly linear chain of command.

As a project manager I don’t have direct control of the shop. There is a director of production, as well as department heads in Carpentry, Metals, Paints, and electrics. When I have a project that is in process the department heads assign me a job lead, chosen based on the type of project, shop schedule, availability, and so forth. This project lead reports to me, but also reports to the Dept. Head. Technical solutions are developed with the PM, job lead, and the department head. While the crews are committed to get every project done successfully, the department heads have to balance all of the jobs on the floor, not just mine. That may mean that while I would like item A to get built on Monday, if there is a more pressing need on a different project, my crew might be pulled off to help another job.

There are multiple things to consider here that is affected by this set up. First, multiple people (PM, Dept. Heads, job leads) need to be in on decision making, and kept aware or schedule updates, changes, and other information. Secondly, you may need to negotiate to get someone on your crew, or the job lead the help they need to complete on time. This is particularly true if the ship or installation date is far in the future as the shop can sometimes focus on the next show out the door. It also affects your leadership style as you can’t micro manage the shop floor, and you have don’t necessarily have direct authority. While the PM is not “powerless”, the PM’s management style, influence and reputation makes a difference in how willing people are to work with you and to work collaboratively.

Tuesday, April 26, 2011

Success versus failure

When I was in grad school there were often discussions about being allowed to fail. Or rather, that more is learned from trying and failing than playing it safe and succeeding. Therefore, we should be allowed to experiment and fail. But failure really wasn’t an option.
I have also heard this discussed at USITT. Those conversations were usually a bit more academic. If a teacher sees a student failing – what do they do? Let them fail? Intervene? If they intervene, at what point? Late enough that the student understands the failure, but early enough for the show to succeed? How does this vary depending on the type of failure? Failure of scenery causing safety issues is very different than a set looking ugly because the students tried a unique painted treatment that didn’t work out very well – or was a bad color scheme.
But what is success and what is failure isn’t really discussed. Is a successful set one that the designer is satisfied with? What about the audience, the designer? If all of the above have different expectations what takes precedence? Can it be a failure to the set designer, but a success to the director? Can the audience be disappointed, yet internally everyone be satisfied? Technically, beyond meeting the client, designer, director (etc.) expectations, the set should be done on time and within budget. The third parameter, quality should be met, but is often most associated with meeting designer expectations. Further there are times when a project might ask for 100%, but 80% realization is still enough to make the project a success in the eyes of the users.
Secondary results of a successful project can mean future work, references, awards. Technically it can mean accomplishing it within OSHA requirements, safety codes, and with a high efficiency or effectiveness.
With failure there are three types:
Planning failure: the difference between what was planned and what was accomplished. In some cases, the project inherently fails because the initial scope is too large.
Actual failure is the difference between what was achievable and what actually was accomplished. This type of failure occurs due to poor performance.
Lastly, perceived failure is the net sum of actual failure and planning failure. If you plan a project that is too large, then a planning failure occurs. If the performance fails on top of that, and there is an actual failure, these are added together to create the perceived failure. The differences in perceived failure can be large depending on how those variables factor out, and are important. Theoretically, increasing planning skill, eliminating or minimizing planning failure can then minimize actual failure. Risk Management can help to eliminate planning failure by helping to identify potential problems in advance and by planning alternatives.
Regardless – unless the failure are captured and considered, real learning doesn’t occur and can’t be passed on. As an industry, we continually reinvent the wheel because past learning technical concepts and methodologies are irregularly kept, and not available. Examples: I know of more blood recipes than I can count – which one is best? I know of 15 ways I can build a rock or a tree or carve and coat foam. Which is best? What does the best alternative depend on? Cost? Time? Materials? Sometime I wish at USITT someone would build 30 rocks, all different and put them on the expo floor- and after 3 days we could analyze the results. Capturing the lessons that are learned, and teaching others those lessons are fundamentally important. But it also helps to realize that these lessons are often viewed from different perspectives.
*Definitions are from Project Management by Harold Kerzner

Friday, April 15, 2011

Changes & Risks

The second chapter of our PM book had a significant section change management. I thought this was interesting because I don’t really think of project managers as being change agents. In both theatre and with the projects I manage (theatre scenery, museum exhibits, TV, and tradeshows) change happens frequently. Projects pop up, go away, get reinvented, change scope, etc. all of the time. Technology changes. What we can do changes as we continue to develop skills. So, it makes sense for PM’s to consider change management as part of a skill set that is necessary to develop.
While our PM book (Harold Kerzner's Project Management: A Systems Approach to Planning, Scheduling, and Controlling. 2009.) discusses the basics of change management (recognizing that change is hard because of fear of the unknown, loss and how to move change forward with enthusiasm, building comfort, finding positive opportunities and incentivizing change), my favorite book that talks about change is Hiefetz and Linsky’s Leadership on the Line. They talk a lot about change, but also about leadership dilemmas, of which I have occasionally found myself in.
The other topic in Chapter 2 (other than the history of project management which is interesting, but not relevant) that we don’t talk about in theatre management is risk management. I think that theatrically this doesn’t get thought about because in most cases the risks are low. There are automation and rigging risks, we have all certainly heard about industry accidents, but more often than not I think the most common risk in theatre is an ambitious design / construction plan that is unattainable. But these smaller risks should be considered. What happens if we can make a lift work the way the show wants it to work? What are the other options? As TD’s we solve problems, and risk is inherent in that process. Sometimes I think it is worth thinking about a little more actively instead of just proceeding full stream ahead.

Wednesday, April 6, 2011

Stop Gates & Check Points

One section of the PM overview that I thought was interesting was the use of stop gates or checkpoints. I have a variety of thoughts about this.
First, I think instituting standard periodic progress reviews is good, and something that should be done more often. Theatrically, most of the review process happens when the show is bid, and casual reviews maybe done for production meetings, but it isn’t a formal process. With the projects I do now, the formality differs on the job, how large it is, the time span that the work occurs over, as well as other variables. But it is not a very formal process either. Perhaps the two most formal attributes would be the initial estimating process, and then the final punch list items.
I think one of the issues with checkpoints is that things often move through the shop so quickly, that the PM has difficulty keeping up. One project manager may have 3-4 (or more) jobs on the floor. The job lead assigned to each only (sometimes) has that one job to worry about. Also, the fast pace often means that a project isn’t fully developed, drafted, items ordered, etc. prior to being given to the shop floor to build. Thus logical transition points for checkpoints become blurry.
The other thing is that in many situations where I work, and in theatre, while keeping tabs on process is critical, the choice between moving forward or stopping the project isn’t realistic. Where I am at now, once we have won the bid, and accepted the award, there is no stopping the project. Monitoring progress is critical, making steps to maintain schedule / scope, and quality despite changes is important, but the point of checkpoints is to maintain those items, not to determine whether to proceed or not. Occasionally there are internal projects that could be subject to internal review and possible elimination (Should we re-engineer the kabuki system? Should we build more winches? ). But it is a critical difference to compare the two, when one process will allow a project to stop, while at other times, the only resolution is how to maintain or regain progress on a project that MUST move forward.

Finally, it is interesting that officially, the project manager working on the project can't make the decision to proceed at a formal checkpoint or stop gate. While this might make since for internal projects that need to be sanctioned by someone higher in the company, it isn't something I encounter either in theatre or in my pm situation. Progress reporting and realligning project goals to maintain schedule scope and quality is a continuing process, of which I am responsable. There are situations where I would need approval (needing additional resources or overtime) but there are no formal points in a typical project process (one the bid is accepted) that I work in where the project must be reviewed by my supervisors to proceed. I think needing to do this would be very challanging in the project environment here, mostly due to the fast pace that most jobs have through the shop.

Monday, April 4, 2011

PM Overview

If you read my blog, I am sure that you know that I am a believer that Technical Directors are very similar to Project Managers. A typical show, by definition, meets the definition of a project in a variety of ways, but there are some differences as well. I am currently taking a formal class on project management, so I expect I will (hopefully) have a number of comments to make about what I learn in class and from the text versus the theatrical point of view and even my point of view coming from the specific types of projects that I am currently managing.
The formal definition of project management requires that projects must cross functional lines. I think theatrically there are a couple ways of looking at that. Obviously, where you are in the organization matters- as the lines that you manage are different. The production manager would be managing the “functional lines” of props, costumes, scenery, lighting and sound. The Technical Director would be managing the heads of carpentry, metals, automation, and paints.
A project would have one project manager and a variety of assistants, if the project was large enough to need them. Viewing the TD as a PM, in a theatre that has a Production Manager may appear to be a conflict of interest as in some ways they can both be viewed as project managers – they are just managing different aspects of the project – or mostly closely monitoring a subset of the work, under which the Production manager more globally manages.
Project managers know a lot about managing a project, communication, dealing with all of the different types of people working on the project and managing, defining, estimating and achieving deliverable, but they may not have the technical skill to actually make the product that they manage. Also, they defer to the department heads (or line managers) on how to accomplish a task, as long as the department head achieves the task according to the expectations set by the project manager. This is very different from my project management experience and my experience in theatre. While the TD may not be the best scenic painter or welder, they can usually perform the task, or teach the task to someone underneath them.
Another point is that PM’s generally don’t have official authority over those assigned to their project. They can’t fire people, or demote them, or give them pay raises or promotions. As a TD I had this control over my crew. As a PM, the department heads control the purse strings, and my job lead may be assigned too many other projects besides my own. Thus in the situation where there are multiple projects taken place, and priorities are always changing, you have to negotiate for time on the floor and resources to build your project. As a TD, even when there were multiple shows to be built, I had control over the flow of all of the work on the floor.
The triangle exists in project management (time, cost, quality). However, all of these objectives happen inside a circle that is made up of the “project stakeholders”. While there are several different ways that you can define project success, you must satisfy these stakeholders for any version of success. This is true in theatre as well, we just don’t think about making management happy, or the board members, or even the audience as we go about our day to day activities.
The class gives 4 main tasks for project managers:
Represent the project – promote the project within the organization, negotiate for resources, establish expectations. This isn’t necessary for theatre as much, because the mission is to produce the plays. Unless perhaps you have a graduate show in a professional shop, or the black box production, negotiation and promotion isn’t necessary. However, promoting communication and expectations still are important activities.
Plan and oversee project workflow; from procedures to targets, monitoring performance and corrective action, these happen in both situations.
Facilitate the efforts of those working on the project also occurs in both.
Manage Project Risk by identifying and developing contingency plans. Some theatres take little production risk (in scenery). Others push the envelope and try a lot of new things.
As defined by the book, a technical director would be an example of an informal project manager where trust, communication, cooperation and teamwork are important and the tasks of management revolve more around methodology, life cycle phases, and core skills.