Page tree
Skip to end of metadata
Go to start of metadata

The purpose of this page is to explore our ideas regarding the purpose, strategies and tactics for UCB project management on the CollectionSpace development and deployment projects.

Overarching Project Principals and Questions

What is the purpose of the UCB project manager vis a vis:

  • The CollectionSpace development project?
  • The UC deployment projects?

For example, is the primary purpose of the UCB PM on the development project to support the entire project in reaching its goals or is it more parochial, for example to support the UCB team on day to day activities? The first is strategic, the second purely tactical support. The first implies a real partnership, the second a reactive support role. Of course, these are two extremes to help illustrate the question.

What relative weight does the PM give to each of these relationships?

  • To what extent does the PM strive to bring the development and deployment tracks into alignment?

UCB deployment priorities often differ from those of the overall development project. The extent to which we need to bring these into alignment will be a primary means of determining what the PM strives for regarding development priorities and how hard the PM advocates.

Regarding the CollectionSpace development project, what role can the UCB project manager play in the following areas?

  • Sustainability and Foundation Efforts
  • “Marketing” communication efforts
  • Staffing strategy
  • Budget allocations
  • Priority setting
  • Scheduling
  • Feature and function definition
  • Feature and function priority setting
  • Keeping project in alignment with:
    •  Strategic goals
    • Mellon commitments
  • Risk assessment and risk mitigation

How can the CollectionSpace Project Managers become a team? Is it even appropriate that they do become a team?  Here are some ideas on how a Project Management team can work together as a team, as well as some of the benefits of doing so.

Regarding working together:

  • I have had good success in both job sharing with another PM within my group/company and with collaborating with other PMs on a project in which multiple organizations each had their own PM
  • The keys to success, I think, are:
    • Each PM has segments of the project for which they are primarily responsible and for which they can be proactive and make decisions (this does not mean unilateral decisions, but decisions that are in alignment with project goals and which keep the project moving forward)
    • PMs have regular opportunities to check in and ensure they remain in alignment, share issues and red flags, successful techniques, work to integrate their pieces in terms of schedule, shifting priorities, risks, budget etc
  • A project is full of movement and change and what was a priority last week can sometimes change the next week; what seemed simple one week might end up being too complex for the project to bear and the PM team can evaluate what to do about this and bring the situation, including questions and recommendations, to the broader team
  • The lead PM will have clear “the buck stops here” privileges and responsibilities
  •  One way in which this will manifest is that the lead PM will make the final decisions on what is delegated to the other PMs

CollectionSpace Phase 2 Preparation

CollectionSpace Phase 2 is a perfect opportunity to establish productive collaboration methods. Working with MMI, etc to prepare for 2.0 phase, it would be very beneficial to do a classic “lessons learned” exercise in which we start with answering the following questions before a kick off meeting. Recognizing the project culture, we probably should name this something other than "lessons learned", for example, "Best Practices Review and Refinement". 

The high level agenda for the kick off meting would be to establish agreements around how to work moving forward
o    What worked really smoothly and why?
o    What worked OK but could be honed?
o    What didn’t work well that we’d like to improve?

It would be highly beneficial for the 2.0 phase to include a monthly (virtual) all-hands meeting in which we answer the questions: “how are we doing?” “what should we adjust”? As preparation for this meeting, the PMs should have already discussed these questions and come into alignment so that if there are challenges or successes that the team doesn’t raise during the meeting, the PMs step up to raise them and they are dealt with during the meeting.

See Lessons Learned and Phase 2 Kick Off for details

UCB focused project principals and questions

Conversation starters

  • Is the PM role on UC Data Services projects strategic or logistical? Is the PM a leader or someone who's sole concern is execution?
    • These are not exclusive of one another. With smaller teams it's pretty necessary that the PM takes on logistical responsibilities. The open question is to what extent there is a strategic role.
  • Let's think about some of the responsibilities, activities, and benefits of the PM's having a strategic role.

PM Strategic Role

A project has strategic goals for which budgeting, scheduling and risk management are important support tools to aid the project reach its goals and achieve success. Someone has to ensure that budget, schedule and risk management discussions and decisions are made within the context of this strategic picture. That person can be the Project Manager. The Project Manager is the evangelist for the project, creating a balance between the team which is building the project and the stakeholders who have provided the funding and often created the institutional environment which enabled the project to form.

Let's imagine the opposite situation in which the PM creates a schedule, makes budget decisions and decides how to handle risk without being fully engaged in questions of relative goals, priorities and scope. These (goals, priorities, scope) are the drivers that should inform the other decisions so that they can be good decisions contributing to overall success. Another area that the PM needs to be involved in is the actual definition what will be built and delivered in order to successfully facilitate, communicate, and ensure clarity of decision and communication. Relatedly, the PM should understand the end-user and their needs. When a project has someone who represents that audience(s) on the team, the PM needn't have as detailed an understanding. But the PM must still have a strong understanding. Imagine the scenario in which a hard decision regarding scope or priority has to be made. How can the PM make such a decision without understanding the trade-offs? Indeed, the PM's strategic job is to ensure that the trade-offs are clearly understood by the team and, if important enough, by the stakeholders, so that a good decision is taken. Let's be clear, the PM doesn't do these things unilaterally but in consultation with the team as a facilitator, evaluator, and often tie breaker when there is either no clear answer or no consensus.

I think of the PM as the orchestra conductor ensuring that all the players are playing in harmony with smooth timing and appropriate interpretation. To do this well, the PM must have a clear picture of the entire project and must be able to course correct. And like a good orchestra conductor, the PM has to leave creative space for the experts who do the work - the musicians, the designers, the coders.

I just wrote "the experts who do the work" as though the PM doesn't do hands-on work and in a large project that is the case - the PM has no time to do so as there is too many moving pieces to keep in harmony. However in other projects the PM will have what Patrick S calls "deliverables" in addition to things like reports and schedules. What these deliverables are will be driven by the nature of the project and the skills of the PM.

Let's think of this in terms of the UCB Data Services projects. These are projects in which the PM will need to do hands-on work. The work will range from the obvious (setting up and recording meetings) to the esoteric (specialized data modeling) to the strategic (getting deep into foundational planning and execution). 

For the PM to be successful, there needs to be clarity about the role and responsibilities before the project kick-off. If the PM doesn't know these expectations, there will be failure even at the kick off because no one will have a clear idea of how the project will unfold and perhaps even where it's going and why.

Similarly, the PM should be part of the staffing decisions on a project. The PM is the person who can work with stakeholders to analyze the project goals, budget, opportunities and risks and help determine the best combination of roles and even specific individuals to put on the project. There will be many ways to staff and run the project and the PM should be able to speak to the pros and cons of different staffing models since this will impact everything from team spirit to speed to budget and risk management.

Tools and Processes

The biggest question on the table with Data Services is if and how to integrate the Agile methodology into our projects. The beauty of Agile is that there are frequent usable deliverables that stakeholders and end users can evaluate and provide feedback to. This can be particularly beneficial when the project is large and unwieldy which open space consortia projects pretty much are. Course correction and subtle adjustments can be ongoing  with each sprint and release providing the opportunity for the entire team to take stock of one another's work and re-adjust alignment.

But for Agile to work it must be well understood, planned and managed - just like any other project process. It's a tool, not a guarantee.

Similarly, other project tools need to be understood, their use designed and managed or they are not necessarily useful. The key to this is using the tool consistently across the team where there are full-team relevancies. For example, we can use JIRA to track tasks, bugs, etc. It works too  - IF - the team has the same interpretation for "major", for time estimates (does the estimate include unit testing, code commenting?), and everybody uses it. If not, it is in danger of demanding more overhead than benefit.

There are a plethora of new and evolving tools and it would be good to evaluate some that seem promising and choose some to pilot with the view of discovering "best practices" for which tools and how to use them across the department's projects.

  • No labels