SHOW ME THE MONEY: BUDGETING

MUSEUM PLANNING AND MANAGEMENT
October 26, 2017

BY: EMILY WELSH

Money, money, money. Money!

Class Insight

This week's lecture focused on budgeting and resource management. In order to understand your project and create an accurate network diagram, you first need to understand all of the resources your project requires. Remember, resources aren't just material things! Your resources required also include people, facilities and space. Your network diagram will vary depending on whether or not your resources are constrained. If you have no constraints, you will be able to complete activities concurrently and thus reflect this by stacking activities in your diagram. If you are constrained by your resources, then you may not be able to complete activities concurrently.

Mapping your resources out over activities can help you even out the allocation of resources and work over time. You want to find gaps that can minimize the amount of time to complete your project. This rearranging of resources is called resource leveling.

When you understand the resources you will need to complete your project, your next step will to be create a budget by estimating activity costs. You can decide to complete your budget in either a top-down or bottom-up fashion. Creating a budget from the bottom-up (by looking at all the tasks and estimating funds required and adding up to see if you meet the funding package) makes more sense to me than a top-down approach. You can start by being realistic in your estimates and seeing if they add up to the amount available. If not, then you look for areas to change or compromise on. Going top-down (eg. I have $600,000; I'll give $100,000 to this part, $200 000 to that) seems harder to do and more unreliable but perhaps there are situations where it is useful.


When making your budget, consider making a time phased budget and not merely an itemized list. If you create a budget that illustrates the costs associated with the different phases of your project, you will have a better grasp of the cash flow over time. This knowledge can be helpful for fundraising efforts and sponsors.

Finally, don't forget your shadow costs! These are items you won't include in your budget but are still important to consider, especially when determining whether a project is worthwhile to complete. An example of a shadow cost is a salaried person's work hours; they would be getting paid anyways and thus their wages don't matter to the budget, but their time is being taken away from the organization for this project! Thus, you want to make sure the project is valuable!

Reading Insight

Chapter 21, "Financial Planning,"  by Zuern in Lord and Piacente's Manual of Museum Exhibitions was a great chapter for putting project resources into a museum context. The chapter begins by listing costs you will typically need to budget for in a museum exhibition project. These costs include direct ones, such as fabrication, copyright permission acquisition and installation, and related costs, such as conservation and public programming.

Zuern also clearly articulates that a budget is not a static entity. You are to revisit the budget frequently during the project and clearly communicate to your team which costs in your budget are to be trusted and which are estimates. As time progresses, more costs will become reliable and known, for example when contracts are signed. As your budget changes you may need to keep making adjustments to components and designs within your exhibition in order to ensure you meet your budget.

I also appreciate the author is very blunt when discussing the common sense solutions for when your items lead to a total greater than that available. You will either need to lower or increase the budget. Lowering costs may include finding cheaper ways to achieve your desired elements, reducing the scale, combining activities, and eliminating items from your plan. 

Source.

 Whatever you do, don't pull from future budget items to pay for ballooning earlier ones! Zuern explains, "assuming that the initial budget allocations were sound, pulling funding from future project phases only postpones the problem - and usually makes it worse, since the time to effectively deal with it will have compressed"  (Zuern, 2014, p. 378).

Happy Planning!       

 
Resources

Zuern, E. (2014). Financial planning. In Lord, B. & M. Piacente (Eds.), Manual of museum exhibitions (pp. 373–378). Lanham, MD: Rowman & Littlefield.

PRESENT AND BREAK IT DOWN

MUSEUM PLANNING AND MANAGEMENT
October 16th, 2017

BY: EMILY WELSH

Welcome to Week 6 everyone! The halfway point of this semester has come and past. Oh where did the time fly?

The majority of this class was spent presenting our project charters to our peers. The last portion was a brief overview of the work breakdown structure and network diagram which I will discuss in the reading insight below.

Class Learning 

Within most of our groups' presentations, we often slipped into providing status reports rather than presenting project charters! It was a good class for practicing our presentation skills as we obviously needed the time and assistance.

Don't fall into the trap! Structure your presentation for the goals you hope to achieve! Source.

Instead of providing updates on where our projects stood at the moment, our presentations should have mirrored the purpose of the project charter. The project charter is a document used to present your project to gain approval, funding, or stakeholder support. Thus the presentation should be structured to achieve these goals!

Here are the recommendations our co-instructors provided us for developing better "pitch" presentations in the future:

1. How you deliver your content can often be more important than what you actually present. If you aren't enthusiastic about your project, who will be?

2. Timing is crucial! If you have a time limit, stick to it. Don't waste people's time. You often lose their attention near the end if you go beyond what was expected.

Use a timer! Know your time limit and stick to it to avoid losing (and annoying) your listeners. Source.

3. Don't read back your written document. Use your presentation as an opportunity to highlight the key points. The listener can read your document if they want further details. Simply highlight that this information is present in the document if you they need it.

4. Make your key points punchy! What about your project will engage your listener and make them want to approve your plan or invest in it? Why does your project matter? Gloss over the negative points of your presentation and make sure you are memorable!

5. De-emphasize planning. Items related to planning are important to your success but aren't of much interest to your listeners in this setting. Stick to the big picture and what sells your project!

6. Use your best communicator! Although you may think it is best to have everyone speak, you only want to have those adept at communicating and holding attention at the helm of the ship in this setting. Know your weaknesses, and if public speaking is one of them, play a supporting role.

Not everyone has to speak! Use your best communicators and public speakers for best results. Source.

7. If you aren't speaking, make sure to watch your body language! Don't lean against walls, look bored or appear distracted. Actively listen to your team member and nod approvingly of their speech. Be ready to support the team by answering questions at the end.

Reading Insight 

This week's reading included three sections of Gido and Clements book, Successful Project Management. I was extremely impressed by the sections I read of this book, and I hope to read more! The sections were easy to follow, incredibly practically, with a multitude of examples and diagrams taking you step by step through the creation of work breakdown structures and network diagrams. I'll be brief here this week because I think instead of reading these notes anyone should just look up this chapter for the best advice and explanation of the concepts.

To begin planning, groups need to agree on the project scope. The project scope consists of everything that needs to be completed in order to finish the project. Once this has been established, the work needs to be broken down into manageable chucks. Thus we see the meaning behind the term 'work breakdown structure'. The work is arranged into groupings called 'work packages.' Each package has one major deliverable associated with its completion and is comprised of a series of tasks (aka activities). Each task may also have its own small deliverable and at this stage you can start assigning group members to the tasks. This structure can be presented in a chart or a list.

The next step is to create your network diagram. Essentially you need to know the sequence of tasks and their relationships or dependencies. Each task receives its own box and the boxes are arranged in the order of events. Boxes may be stacked in concurrent or laddering patterns to show more complex and time efficient relationships. 

A time duration is assigned to each task and this diagram can be used for the project scheduling, which may take the form of a Gantt chart. The book does an excellent job of walking the reader through the determination of the total slack and critical path of their project and the consequences of positive and negative values. The authors also give you tips for estimating duration of tasks. For example, don't forget that the duration is the total time elapsed! You need to take into account not only the time you will need to do the work, but also the time you will spend waiting!

The authors' considerations let you figure out whether your project, with your estimated task durations, will meet the completion date and if not, how to consider adjusting tasks to alter the slack in the timeline.

Happy Planning!

Resources 

Gido, J., & Clements, J. P. (2015). Successful project management (6th ed.). Stamford, CT: Cengage Learning.  

READY, SET.....PLAN!

MUSEUM PLANNING AND MANAGEMENT
October 10, 2017

BY: EMILY WELSH


Happy Belated Thanksgiving everyone!

This class fell on Thanksgiving Monday! Source.

Week 5's class fell on Thanksgiving Monday and thus we didn't have an in-person class. Instead, we perused the week's materials on our own time.

Class Learning

This week's material covered the responsibilities and characteristics of the project manager, how to create the project team, support them through the project life cycle, a nine step problem solving strategy, conflict resolutions strategies, and finally considerations for the types of meetings, procedures, documents and communication methods your team will use during the project.

It is crucially important to plan out the methods for completing your project early on and communicate them to your team in a kick-off meeting to ensure everyone can proceed in the same fashion and understand what is required of them.

Plan out how you will complete the project, (What kind of meetings will you use? How will the team communicate? What are your procedures?) and review this plan with your team! Source. 

Although much of the material presented was straight-forward and doesn't merit deeper discussion here, I found the topic of delegation to be quite interesting. I hadn't realized that there are different degrees of delegation that likely depend on how willing you are (either consciously or unconsciously) as a project manager to give control of a task to your team member. The highest degree asks the member to investigate the problem, take action and decide if they want to inform you of the action. The lowest degree asks the member to investigate and report on the problem, and you, as the project manager, decide what action is taken and who completes it. The barriers to delegation were listed as thinking you can do the task better, lacking confidence in your team, being afraid of losing control, fearing criticism, and lacking self-confidence. A good project manager would be able to keep these barriers in check to make a sound decision on how much to delegate to the team, as delegation is key to ensure you use the time available and the skills of your team in the most efficient manner.

I also found the review of meeting protocol to be quite helpful. Before the meeting you should take time to review the purpose of the meeting and whether it is necessary, define and invite the participants, hand-out an agenda (or perhaps a less formal description of the meeting), and prepare any required materials. At the meeting, review the purpose of the meeting with the participants. I think this is a key step because if members understand why the meeting is valuable and what is supposed to be achieved, you will be able to keep their attention and interest better and limit discussion to what is absolutely necessary.

Reading Insight:

The reading I would like to highlight here are two chapters from Macdonald's book, Behind the Scenes at the Science Museum. Pages 91 - 156 discuss the planning and development of a permanent gallery in the late 1980s for The Science Museum. The theme of this gallery would revolve around food. The chapters provide an excellent case study of a large scale project and the iterations it moved through including issues during the development phase in which the team faced issues which border on scope creep. Alternatively you could more aptly describe the issue as 'initially biting off more than one can chew.' As they researched the content, built the narrative and selected objects, the team found they had more content that they could feasibly display. When presenting the content to the Director, the Director also questioned their narrative and what the messages were. With the amount of content he was confused as to what the exhibition was trying to say to the visitors. When altering and trimming their content, the team had to think about what really mattered to their message; a concept that clearly illustrates the term interpretive plan we use today. Knowing your goals for the exhibit and having a solid curatorial thesis or big idea can help filter what really matters to the project. However, the team ultimately had to alter their big idea.

Most interestingly the author is a researcher who did not play a large part in the project itself. She examines the project and describes it's progress, issues, ideas, team dynamics and museum relationships from a viewpoint more distant from than if it had been written by one of the curators or the project manager, who may be more subjective and emotionally charged. The author refers to her work as ethnography and in this fashion the readers get a better view of both sides of the dilemmas and situations found in the story and gain better insights for their own projects.

Happy Planning!

Resources

Macdonald, S. (2002). Behind the scenes at the Science Museum. Oxford; London: Berg.
    

THE CHAMELEON: AGILE PROJECT MANAGEMENT

MUSEUM PLANNING AND MANAGEMENT
October 2, 2017

BY: EMILY WELSH

Class Learning:

Traditional project management mirrors the idea of a waterfall; the stages of the project cascade, one after another, down to the finished project. Gravity ensures water doesn't travel back up. You may even consider the project manager to be like gravity, ensuring the project stays on track.  However, depending on your project or group dynamics, this model may seem too rigid. Is this the only model for project management?

Traditional project management methodologies resembles a waterfall; one project phase flows into the next - down, down down, to the finished project (the pool). Source.

Today's class introduced the methodology called agile project management. For a quick 2 minute introduction to the topic and its characteristics, priorities, and origins, check out this video:

The key feature I drew from the model was it's ability to allow teams to easily respond to changes required in the project plan. Agile management allows for corrective courses of action; it is iterative and modular. Instead of a project phase being completed all at once and right after the last one, phases in agile management may occur simultaneously and repeatedly.

To begin, the project team gathers the features that might need to be completed for the project's completion. Some of these features will be accepted by the team and then they will be planned, designed, tested and implemented. At the same time as these features are being developed, the team can gather more features and repeat the same processes. In this fashion, if the team forgets a key feature, but remembers it later, they can easily throw it into the new run of features being considered and developed. In the waterfall, it is much harder to bring in a new feature such as a digital interactive for an exhibition, when you have already proceeded through all of the planning, designing, and testing for everything in your exhibition.     

I think of agile project management like a chameleon; the methodology allows you to adapt to your environment and easily respond to change. Source.

You can think of the process as a series of columns in a table. From left to right you would have columns such as features, development (to do and done), testing (to do and done), implemented and done. Team members and specific features of the project can be at different stages of the process. You can keep track of the tasks and their progress using sticky notes on a board or a digital software such as Trello.

Agile project management can be organized with simple sticky notes and a modular chart, or you can use digital platforms such as Trello. Source.

Within agile management there are many strategies, one of which is Scrum project management. Scrum consists of a series of "sprints" with a set duration of time. All of the features for the project (or everything that may be needed to completed) is listed in the Product Backlog. When a sprint is initiated, a series of features are selected from the Product Backlog to create the Sprint Backlog; this is the work that will be completed during the sprint. During the sprint, the development team members work in collaboration with daily Scrum meetings to complete the tasks of the sprint. At the end of the sprint, the team produces a deliverable in one form or another. For example, a sprint may be planned to review the institution's collection to obtain information required for understanding which exhibition narratives are possible. The deliverable may be a written report of their findings. The team then sits down with the Scrum Master (the project member overseeing the process) and Product Owner (the individual determining project requirements and priorities) for a sprint review and sprint retrospective; these meetings examine the work that was completed and lessons learned to be applied to the next sprint.

The most useful aspects of Scrum management in my opinion are the daily scrum meetings, the idea of sprints and the logistics of planning.

The daily scrum meetings asks members of the development team to state what they did yesterday to help achieve the project's goals, what they will do today to work on the tasks, and what barriers do they see that may prevent them from achieving the project goals. This meeting is very brief. I like this type of meeting structure because it allows everyone on the team to be on the same page as to the work already completed, work remaining to be done, and work being done by which members. The meeting also gets members to verbalize problems they may otherwise internalize; problems can't be fixed if you don't voice them. However, you would want to adapt this idea to your own needs; you may not need a meeting every day.

Secondly, the idea of breaking the tasks into chunks that are timed and have set deliverables at their conclusion helps to keep the project moving forward and feasible.

Finally, Scrum management plans for one sprint at a time; you do not plan for the entire project from the onset. This planning strategy is useful as some items you need to plan for will only become more clear farther down the line when constraints and assumptions have been clarified. However, you should still think about the full timeline and end stages; you need to know your end goals (such as date and budget) as well as a rough plan. For some projects it may be better to focus on agile planning (rather than sticking to a strict process) and aptly respond to change.


Reading Insight: 

Cobb's Chapter 6: "Agile Project Management", in Making Sense of Agile Project Management, provides further insight into agile management, Scrum management and its characteristics. He explains there is no dedicated project manager within the Scrum model although a team member, the Scrum Master, will have to complete some of the traditional duties one would expect for managing a project. Agile management is a collaborative process in which many decisions are made as a team and the team is self-managing. The Scrum Master acts more as a facilitator than a director and is likened to a sheepdog tending its herd:  "He/she keeps the sheep from straying too far out of the group and protects the flock from unwanted interference and obstacles" (Cobb, 2011, p. 102).

The reading used the metaphor that the team member exhibiting the project management tendencies in the agile method is comparable to a sheepdog! Source.

Cobb also highlights the collaborative nature of agile management and its relationship to verification and validation. The terms are defined as the following:

"Verification means that the product has been determined to meet all documented
requirements and specifications—“Is the product right?”

Validation means that the product meets the customer need that it was
intended to fill—“Is it the right product?”" (Cobb, 2011, p. 115)

Cobb explains that traditional models place emphasis on verification and only seek the validation of their projects in end stage testing practices. This can be bad news for the project if at this stage of the game the product is found not to meet the needs of the user. On the other hand, agile management, with its emphasis on collaborating closely with users in design and development phases, is more likely to verify and validate the user's needs.  

Although a strictly agile project management method may seem strange, risky, or unusual for your project or management style, there may be aspects of the method you can combine with a traditional model to improve your project planning and management! Never use a model exactly as it comes out of the box - adapt it to the unique needs of your project!

Happy Planning!   

Resources: 

Cobb, C. G. (2011). Agile project management. In Making Sense of Agile Project Management (pp. 101–30). Hoboken, NJ: Wiley.