While the relative level of formal authority vested in a project manager is greater in project-oriented (formerly projectized) organization structures than in matrix ones, the downside of this authority is that the project manager will spend much more time on people management administrative activities such as performance evaluations, hiring and supporting their professional development. While this is important work, it doesn't directly relate to the management of their projects and they might perceive it as a distraction.
In addition, in those organizations which are purely project-oriented (i.e. everything they do is project work with no functional or matrix structures to be found elsewhere within their walls), when projects end, if the team members who were contributing to them cannot be deployed to different projects then they may find themselves out of a job which is likely to stress their project managers even more at the very time when they are trying to line up other projects for themselves.
But there is a silver lining to this people management cloud.
Having these responsibilities will force the project manager to learn about the hopes, dreams and career aspirations of their direct reports. This should provide them with a greater ability to enable them to connect the team members' individual purposes to the success objectives of the project. They will also be better positioned to understand the competencies over which their staff wish to gain mastery which they can use to identify opportunities for personal development for these team members. Finally, even as project managers working in matrix structures will need to learn how to effective delegate, empowering their staff to work with autonomy is even more critical when there is a formal reporting relationship in place.
Project managers in project-oriented organizations might chafe at the additional responsibilities they have to shoulder, but these also give them more power to inspire their team members.
A lot has been written about the challenges caused by functional managers when their company undergoes an agile transformation. But with this emphasis on what they shouldn't be doing, not as much gets published about the specific activities we should be doing to help them through the change.
Here are four questions to ask when considering this key role.
Are they learning?
To support a change you need to understand the change. Delivering training focused specifically on what functional managers need to know about agile which includes scenario-based learning to understand what sorts of behavior changes are expected when faced with common situations will help. But it is also important to identify which managers have already shown evidence of having embraced an agile mindset and recruit them to help support their peers who will have a harder time with the transition. In the absence of such internal support, coaches could be hired to create a critical mass of change advocates among middle management.
What are they measured on and what are they measuring?
Metrics aren't the sole driver of behavior but they do draw a lot of focus. As Tony Robbins would say, "Where focus goes, energy flows". If we haven't updated performance measures for functional managers and their staff, it will be much harder to encourage them to change. If existing metrics are focused on how well team members and their managers achieved certain objectives but didn't also consider how those objectives were achieved, deadlines and budgets will continue to dominate rather than collaboration and engagement. These measures need to be augmented with ones specifically assessing stakeholder and team member satisfaction to understand whether the "how" was as good as the "what".
Who are they hiring?
I've written previously about the importance of adjusting job descriptions and hiring criteria but it is equally important to train functional managers on how to leverage these changes. If the job profile calls for servant-leadership but all the functional manager asks about is what a candidate accomplished, the risk of hiring people who are not aligned with the new way of working will persist. Pairing functional managers with properly trained HR staff for panel interviews is one way to address this.
How are they supporting their staff?
Team members will be experiencing many of the same fears and doubts that their manager has about the transformation so it is important that functional managers meet regularly in both one-on-one and team settings to address these concerns. Managers play a critical role in helping their staff gain the confidence to take their first baby steps towards self-organizing and becoming T-skilled. To do this, managers must cultivate a psychologically safe environment within their teams so that their team members feel safe about expressing themselves and taking chances both in the project roles and in their functional ones.
Buy-in from middle management is necessary for any successful organization change, and even though you might think that the sandwich approach of committed senior leadership and enthusiastic front line staff squeezing out compliance, actively guiding and supporting functional managers will be essential to a sustainable transformation.
(If the title of my article for this week has you confused gentle reader, fret not - I'm just merging two distinct topics into a single post)
In 2003, Barry Boehm and Richard Turner coined the acronym C.R.A.C.K. (Collaborative, Representative, Accountable, Committed, Knowledgeable) to cover key characteristics of an effective Product Owner (PO). Unfortunately, some POs leave us with the perception that they might have been smoking crack!
Having worked with some POs who lack one or more of these attributes, I recently had an epiphany. I have always felt that there is no single delivery role which is the most critical, but my exposure to ineffective product management has convinced me that the PO is the hardest role to successfully fill.
Good agile leads (a.k.a. Scrum Masters) might be worth their weight in gold, but they are out there. If you aren't getting good ones the cause is not likely a lack of supply but rather blockers within your own organization (e.g. toxic culture, poor compensation) which are preventing you from attracting them, and in a pinch, contracting might be the way to go. Development team members are also valuable, but talent across most skill areas is available for the right price and with the right culture in place.
The challenge with the PO role is that not only do you need someone who has deep business process knowledge regarding the product they are supporting, but they also need to have well established relationships with key stakeholders who will influence product direction. While it is difficult to satisfy the first requirement, especially in those organizations where knowledge exists in silos, it is much more difficult to meet the second requirement. Simply parachuting in someone from the outside won't work regardless of how knowledgeable they might be about the domain.
So if you are lucky enough to have an effective PO, retain them at all costs.
On a different note, Eric Uyttewaal, asked whether I would be interested in reviewing his latest book - Forecasting Programs - Best Practices for Scheduling Real-World Programs.
I don't normally write reviews on my blog, but I have deep respect for Eric's knowledge of MS Project and his ability to make it able to stand on its head. Eric has written multiple books on effectively using the tool and given the dearth of guidance on using scheduling tools like MS Project to manage programs, I felt this was a worthwhile exception.
I was pleasantly surprised to see that the book goes beyond MS Project to providing general scheduling guidance for managing programs. While the examples and step-by-step procedures do focus on MS Project, they can be adapted for use with other scheduling tools.
Eric has done a good job of covering the analysis which a program scheduler might go through in deciding how to organizing their schedule, and I especially liked his Project Ideal and Constraint Matrix (PIC-Matrix) which can help a scheduler in deciding which scheduling approach to use given the primary expected benefit and primary constraint for a given program.
While there is guidance for scheduling projects following an adaptive lifecycle, Eric has taken a very narrow view of agile delivery. Sprint-based delivery might be the most commonly followed approach but it is not the only one. His compromise to find a happy scheduling medium by defining the content of a full backlog in detail so that work items can be assigned to all sprints and estimating all backlog items is not suitable for projects where requirements are expected to evolve dynamically. His approach to converting story points to effort hours is also concerning as there usually isn't a linear relationship between the two.
Eric's company develops and sells a number of add-on products to MS Project. While a certain amount of self-promotion is to be expected, I did find that the number of references to these products was more than I would have liked. In fairness, Eric does reference other third-party tools but generally positions his tools favorably relative to these competing products
I felt the book's greatest strength is the number of options which Eric has provided for scheduling programs which makes this book useful regardless of the maturity level of the practitioner.
A past article I'd written covered the importance of preparing your team members to tackle a new project.
But what happens when a new team member joins in the middle of the project?
Onboarding is the complete set of activities which get performed when someone joins a company – providing their system access, finding them somewhere to sit, introducing them to their co-workers and so on. But onboarding is also crucial when an existing employee joins a new project – without this they are likely to feel disconnected from the rest of the team, and may not commit themselves fully to the project’s success.
Is this really necessary? After all, the new team member has likely worked for the company for a while, already has an assigned workstation, knows his or her co-workers and will probably understand what’s expected of them.
That may all be true, but a specific project’s team culture can be quite different from the culture of the department or organization as a whole. While the new team member may have worked on projects before, the specific practices which your team is using may be different from what they were used to before. They may not know all the other team members, especially if it is a cross-departmental project.
So what are some steps to properly onboard a new team member?
Prepare for their arrival. Just as you would want to ensure that a new employee’s workstation, computer, phone and e-mail access and even business cards are ready before their first day, make the new team member feel that their joining was not a surprise by informing the rest of the team of the new arrival in advance, finding a spot for them to work and confirming their access to project documentation and other applications.
Introduce them to your sponsor and all of the team. This seems like a small thing, but if they have never worked on a project for your sponsor before, establishing that connection will likely make the new team member feel that their contribution is valued. While they may not work directly with the full team, they will be equal custodians for the team’s ownership of its practices and work products so it is important for them to know and be known by all.
Hold a mini-kickoff meeting welcoming them to the project. While the primary audience will be your new team member, you should use it as an opportunity to do some team building, to reinforce key messages about the project’s vision and remind the whole team how important everyone’s work is to achieving that vision. Have your existing team members share some of the key rituals which are part of the team’s culture.
Find them a project buddy. Whether it’s one of the existing team members they will be working closely with, or someone leading a different work stream, identify a willing “go to” person who will help support them in their first couple of weeks. This is a great way to make the whole team responsible for supporting one another, and will reduce the draws on your time.
You’ll never get a second chance to make a good first impression, so onboard new team members with the same thoughtfulness as you’d show to a new employee!
(Note: this article was originally written and published by me in May 2015 on my personal blog, kbondale.wordpress.com)
Testing a candidate's knowledge of hard or soft skills provides limited benefit to the hiring process. If they have the letters ", PMP" or ", PRINCE2" after their names, they can very likely talk the talk even if they've never walked the walk.
You could pose situational questions to gain some insights into how they think, but just because they answer the question to your satisfaction doesn't necessarily guarantee that they will actually behave according to what they said if a similar situation were to occur for real. Don't feel discouraged as conducting such interviews is still critical, but you might want to go beyond assessing technical knowledge or posing generic scenarios.
Let me share five of my favorite questions when interviewing candidates for full time project manager roles.
What's been your biggest project management failure, what did you learn from that, and how did you apply those learnings to a future project?
This question is a triple threat. It assesses the self-awareness and humility of the candidate, their ability to dust themselves off and identify some lessons, and checks whether they truly learn those lessons.
How do you stay current in the project management profession?
There's no single right answer, but if a candidate has been neglecting their personal development this doesn't inspire confidence. Also, if their only lever for personal development has been formal training, this reflects superficiality as some of the best opportunities to grow come through experiential or relationship-based development activities. You will also have the opportunity to understand if they are giving back to the profession through volunteering, writing, presenting or mentoring others.
What made you decide to become a project manager?
Again, no right answer, but it provides insights into the candidate's career goals. Is project management a stepping stone to something else or is it a long-term destination?
What do you consider when deciding how you are going to manage a given project?
This question tests the candidate's ability to profile a project and the context in which it will be delivered as well as their awareness of complexity and delivery process tailoring.
What questions do you have for me?
"Judge a man by his questions rather than his answers" - Voltaire
So what are your favorite questions when you've been in a similar situation? Feel free to add them in the comments below!