In my PM class, one of my classmates shared a link about How to Finesse Budget Discussions. While as a TD in a theatrical situation, some of these options don't fit, the situation is still ripe for a scope to creep beyond the budget (time or materials) allotted for the show. It happens with the best of intentions - we all want the show to be a success. The range of options and the sampling I think could be effect techniques for theatre.
By giving options you can show how increasing the level of detail increases costs. However, we still have to be careful - a current production I am working on includes a caboose (a whole train really) - the caboose has vertical stripes. (the bigger story is that I interpreted the striped as engraved groove & my coworker thought they were dimensional (proud) trim - two different scenarios). It was offered that these could be painted instead of dimensional. If they were proud dimensional trim strips, you would save material costs by eliminating the trim. If they were grooved you would save time making the grooves. My vote is for grooves though - the cnc router can cut the panels to size and groove the plywood in 15 minutes. If they were painted only the painter would have to measure everything out and mask off the surrounding areas & ultimately spend more time than simply following the groove with the brush. Even the difference in proud trim versus paint is a marginal trade-off to me. If the lines weren't regular, or weren't prefect allowing the use of a paint stick. This leads into sampling - item A perhaps is a straight edge with brush stroke, item B is a groove and paint, and item C is an applied piece of painted trim. Each one of these would have different cost implication, especially once extrapolated into a square foot cost over a large area.
Monday, May 16, 2011
Thursday, May 5, 2011
Pert Time Calculations
Pert Charts are one of the tools PM's or TD's can use to track projects. While usually used for large and complex projects (For instance Disney could use this system while designing a new ride through implementation and final opening). Pert charts (as does critical path charts) focus on time, not cost as a project driver. Once all activities are entered, with time durations, and predecessors or successors, you can easily see the length of the project by seeing the critical path through the activities.
The critical path will be the path through the path that is the longest duration. There may be a variety of projects that need to be complete prior to project close, but sometimes they do not directly affect project length. There is a lot of information amount PERT charts, CRM, Gantt charts and network diagramming on the web, all of it much more thoroughly written then this so I would encourage you to do additional research.
When doing a PERT, Optimistic time (the minimum time needed) Pessimistic time (Worst case scenario) and Most likely time (best guess) is estimated for each task. What I just learned was how that gets translated into the Expected time duration:
Expected time=(Optimistic Time +4 X Most Likely Time + Pessimistic Time) / 6
Thus, the weighted average of the times creates a realistic duration. Since I usually do all of my estimating in excel workbooks, setting up these PERT calculations would be fairly simple (though perhaps tedious) to implement. It would be an interesting exercise to see if this ultimately leads to an increase in accuracy large enough to account for the additional estimating time.
One can argue that historical data and experience alone lead to better estimates, and to a certain extent that is true, but there are many variables that can affect the actual duration of any task.
Where I currently work we base our hours estimate on skilled labor doing the work. In many cases it is skilled labor that does the work, and the estimates can be fairly accurate. If the shop is full of work, and additional crew is hired, unskilled work (or lower skilled workers) may be put on the job, but their labor rate is also lower – so while the hours calculation will be wrong, the assumption is that the total amount being billed for the hours would work out due to the differences in labor rates. Sometimes this is true, and sometimes it is not. Historically we used to estimate based on who was slated to be assigned to the work. This lead to specific estimates based on the jobs leads capabilities. These estimates could be a little more specific, but were not generalizable, and were more time consuming. And despite being more specific were not any more accurate in the long run. Since we track the hours estimated vs. used, as well as the cost of labor estimated vs. used, it is interesting to see how these numbers can play out.
The critical path will be the path through the path that is the longest duration. There may be a variety of projects that need to be complete prior to project close, but sometimes they do not directly affect project length. There is a lot of information amount PERT charts, CRM, Gantt charts and network diagramming on the web, all of it much more thoroughly written then this so I would encourage you to do additional research.
When doing a PERT, Optimistic time (the minimum time needed) Pessimistic time (Worst case scenario) and Most likely time (best guess) is estimated for each task. What I just learned was how that gets translated into the Expected time duration:
Expected time=(Optimistic Time +4 X Most Likely Time + Pessimistic Time) / 6
Thus, the weighted average of the times creates a realistic duration. Since I usually do all of my estimating in excel workbooks, setting up these PERT calculations would be fairly simple (though perhaps tedious) to implement. It would be an interesting exercise to see if this ultimately leads to an increase in accuracy large enough to account for the additional estimating time.
One can argue that historical data and experience alone lead to better estimates, and to a certain extent that is true, but there are many variables that can affect the actual duration of any task.
Where I currently work we base our hours estimate on skilled labor doing the work. In many cases it is skilled labor that does the work, and the estimates can be fairly accurate. If the shop is full of work, and additional crew is hired, unskilled work (or lower skilled workers) may be put on the job, but their labor rate is also lower – so while the hours calculation will be wrong, the assumption is that the total amount being billed for the hours would work out due to the differences in labor rates. Sometimes this is true, and sometimes it is not. Historically we used to estimate based on who was slated to be assigned to the work. This lead to specific estimates based on the jobs leads capabilities. These estimates could be a little more specific, but were not generalizable, and were more time consuming. And despite being more specific were not any more accurate in the long run. Since we track the hours estimated vs. used, as well as the cost of labor estimated vs. used, it is interesting to see how these numbers can play out.
Tuesday, May 3, 2011
Unmanila Rope
UnManila Rope is a product I am using on a current project. While it will degrade under sunlight, it was important to look like authentic nautical rope, without splintering like hemp or manilla. While I wouldn't consider this for rigging, and it great for decoration, and it comes in a variety of sizes.
Monday, May 2, 2011
Project Management Skills
In many ways, the lists are similar from being a TD to being a PM. Since I am a management focused TD (as opposed to a master carpenter style TD), my views are skewed accordingly…
The largest differences I see is that dealing with clients is different (in some ways) than dealing with designers (or internal clients, as a PM text would say), and the need to write a proposal or scope of work that clearly defines what you are providing to your client and for what price.
In terms of technical skill there are some differences. I have always believed that the TD, by nature of their responsibilities and skills, is a management position, and therefore should understand all of the technical areas, needs, safety requirements, and so forth (and have the appropriate certifications), but they aren’t & shouldn’t be the best welder in the shop. You can’t spend 40 hours a week on a diversified set of job tasks and be better than someone who spends 40 hours a week welding. In project management, I feel like this is the same, but even more so – the department heads, have been doing their jobs longer than I have, and have very specific skills. I have a generalists knowledge – I have to rely on, trust, negotiate and motivate them to seek out the most efficient processes, and to innovate as needed.
Otherwise, there are the typical skills: drafting, drawing, communication (verbal, written, illustrative), problem solving, time management, stress management, budgetary, computer literacy, adaptability, flexibility and versatility.
Also, there are management skills: conflict resolution, negotiation, planning, human resources, legal issues (fair employment, sexual harassment, osha requirements, life safety codes), organization, and so forth.
Finally, there are leadership skills: being able to see details, yet see the large picture. Being able to forecast what’s coming and prepare. Manage change. Motivation of those around you. Create a culture of trust, respect, innovation, planned risk, and celebrate success. Provide an organizational structure that works, a humane place to work, meaning in the work place, and navigate office politics.
Of course the above is my opinions, and abbreviated at that. Many books are written about much of what I have stated above. What are your thoughts?
The largest differences I see is that dealing with clients is different (in some ways) than dealing with designers (or internal clients, as a PM text would say), and the need to write a proposal or scope of work that clearly defines what you are providing to your client and for what price.
In terms of technical skill there are some differences. I have always believed that the TD, by nature of their responsibilities and skills, is a management position, and therefore should understand all of the technical areas, needs, safety requirements, and so forth (and have the appropriate certifications), but they aren’t & shouldn’t be the best welder in the shop. You can’t spend 40 hours a week on a diversified set of job tasks and be better than someone who spends 40 hours a week welding. In project management, I feel like this is the same, but even more so – the department heads, have been doing their jobs longer than I have, and have very specific skills. I have a generalists knowledge – I have to rely on, trust, negotiate and motivate them to seek out the most efficient processes, and to innovate as needed.
Otherwise, there are the typical skills: drafting, drawing, communication (verbal, written, illustrative), problem solving, time management, stress management, budgetary, computer literacy, adaptability, flexibility and versatility.
Also, there are management skills: conflict resolution, negotiation, planning, human resources, legal issues (fair employment, sexual harassment, osha requirements, life safety codes), organization, and so forth.
Finally, there are leadership skills: being able to see details, yet see the large picture. Being able to forecast what’s coming and prepare. Manage change. Motivation of those around you. Create a culture of trust, respect, innovation, planned risk, and celebrate success. Provide an organizational structure that works, a humane place to work, meaning in the work place, and navigate office politics.
Of course the above is my opinions, and abbreviated at that. Many books are written about much of what I have stated above. What are your thoughts?
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.
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
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.
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.
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.
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.
Wednesday, March 16, 2011
Velstick
Velstick has a variety of products that could be very useful in theatrical applications. I am using Velstick, itself for a project, to hold some vinyl mattresses into place. It is appealing since it can be anchored with fasteners above just the sticky back adhesive and staples. However, the corner mold, studs, u-clips, and valance corner pieces all seem very interesting. The above link has large minimum's, but it is available at other sites with small minimum orders.
Subscribe to:
Posts (Atom)
