Six elements of managing people

A large part of my role – and a passion of mine – is helping people develop their careers. I have two people on my team currently whose next logical step is to start line managing others so I was going to document some of the things I do as a reference point for them, but then it occurred to me that if I posted it here I could get feedback from other professionals to help me develop, so here goes…

1. Self-assessment

 The people I manage are all project professionals – project or programme managers - so the first thing I do is have them all complete a self-assessment based on the International Project Management Association’s (IPMA) competencies. This means that if in future they decide to align themselves to a professional body, typically the Association for Project Management (APM) or the Project Management Institute (PMI), they will be able to point to knowledge and experience gained in each body’s competence framework.

 To help this, I’ve mapped the APM to PMI competencies to give people flexibility. I need to do both as my team is spread across four countries and three continents.

 Once each person has completed a self assessment of their existing knowledge and experience of each competency – I guarantee the assessments are confidential between me and the individual – we agree on objectives for the next twelve months based on those competencies where they scored themselves lowest AND the needs of the company; I’m strongly against “box ticking objectives” as I think they are demotivating and a waste of the company’s money.

 In addition to these very focussed objectives I always try to give people one or two “stretch goals” – things above and beyond the day job that contribute to the company or to our team’s continuous improvement and in turn to the individual’s skills set. 

1. Make time

I make myself available whenever anyone needs to talk to me, but we also have formal one-to-one meetings once a fortnight. The PMs understand that these sessions are their time; they dictate the agenda and can discuss issues with a current project, career goals or whatever else is on their mind.

Having said that, I also use those sessions to occasionally prod about how certain objectives are going, just to keep people focussed, and to give them feedback on their performance. No surprises in my annual appraisals!

Where I have direct reports who are also line managers I do “Skip reviews” twice a year; by this I mean I skip one reporting level to have one-to-one reviews with the direct reports of my direct reports. This helps reassure me that line management across my extended team is consistent and gives people a confidential forum to express concerns or issue up bouquets for their line manager.

1. Career planning help

 I’ve given everyone in the team a career-planning mind map using The Brain software (check it out, it’s a brilliant application!). It maps things such as career goals, short-term goals, what they already have to help them reach the goals and what they need (possibly from me) to help them achieve their goals. They are free to use it and share it or decide it isn’t for them – their choice. They know that they can say within it that their long-term goal is outside of project management and I will help them work towards another path if that is what they want.

 Where it has been used and shared with me it has facilitated great discussions where we can both plan in depth the route someone wants to take and how best they can achieve it.

 I also encourage them very strongly to use a Continuing Professional Development log – hard to avoid these days if you want to advance in any professional capacity, and a great way to track your progress and prove commitment if you seek any professional recognition such as the APM’s Registered Project Professional status. 

1. Regular, planned one-to-one meetings

I like to use MS OneNote to keep track of my one-to-one meetings. I have a section for each project manager. In it, I list personal things like their hobbies, number of children etc. because it’s important not to lose sight of the human side and life outside work. I also list their objectives there for ease of reference, and have a separate page for each one-to-one. Between meetings I note on the next page praiseworthy things they have achieved since the last one, reminders about things we have discussed in the past and should revisit and sometimes notes to jog their memories about an objective particularly relevant to what they are doing at present.

 Of course, outside of these meetings I never miss an opportunity to recognise when someone has done a good job. Most people respond well to praise for a job well done and I would hate people to think I take them for granted. 

1. Catch them “doing it right”

 One of the most important tools I use is a document of “Positives” for each of my direct reports. In it, I note every time they have done something I’m particularly grateful for or admire. I also welcome feedback from peers and stakeholders about how individuals are performing so that I can include that in the document. This makes the annual review a breeze, as I can draw on things they might have done even eleven months earlier and reaffirm my appreciation.

 What I don’t do is keep a document of negatives! They are discussed straight away. We learn from them and then we draw a line under them. 

1. Track progress

 Finally, I keep a table of people’s job titles, when they were promoted to their current role, what relevant qualifications they have and what qualifications they should be aiming for next to keep them driving towards their medium- and long-term career objectives. This helps me start forming potential objectives for the next appraisal period.

 I think it’s important to identify meaningful training courses/exams for people, to be paid for by the company to confirm its commitment to people. I remember reading somewhere once (probably LinkedIn); a CFO says to a CEO “What if we train our people and then they decide to leave us?” to which the CEO responded, “What if we don’t train them and they decide to stay?”

 The whole basis for all of this is to encourage continuous improvement – of the team, of me, of our processes. The annual appraisal should be nothing more than the formal documentation of what we discussed during the year. If it’s worth saying, it’s worth saying now. Don’t wait for an artificial meeting just because the company mandates one.

 I realise everything I’ve described is a very mechanistic approach to management. Soft skills are more difficult to document, but what I would say is never forget you are dealing with human beings with lives outside of work and let them see that you too are a human being with a life outside work.

 For what it’s worth, that sums up my approach to managing people. Over to you – how do you think I could improve my approach?

 Steve Syder is a Registered Project Professional, a Fellow of the APM and an RPP Assessor. He has in his time implemented Programme and Project Management frameworks for organisations as diverse as the UK Hydrographic Office, EDS and Orange amongst others. Until recently he was Director of Programme & Project Management at OpenBet, and he has now turned his attention to the creation of an international programme and project management function at Tyche Consulting.

Three Essential Ingredients for Lasting Change

We are regularly told on LinkedIn that change is difficult because “people do not like change”, but if that’s true why do people clamour to change their mobile phone even before the current contract is up? Why are shops always full of people looking for new clothes? Why are hair salons busy with people wanting a fresh hairstyle, and why do we sit on the train in the morning, quietly admiring our new shoes? (OK, maybe that last one is just me then, but you get my drift.)

I think what is probably more accurate to say is that people do not like imposed change. Successful, lasting change in the workplace needs to be handled carefully, and people need to be involved. These are the three essential ingredients for successful change I have come to understand over many years of involvement in structural and business change:

Collaboration

It’s far better to say to people “Let’s move over there because it’s better” than it is to say “Come over here – my place is better.” When I introduce change I use a mechanism that involves people so that they contribute to the nature of the change and so feel part of it and buy into the change.

Here’s how it works; I produce a brief proposal document. There are certain guidelines for it: no more than five or six pages; writing should be both precise and concise. I consider the audience and cut out unnecessary words – often adjectives – and no “weasel words” such as “fairly”, “comparatively” and so on. When writing about things that have been measured I always include numbers and evidence.

I also try after every sentence to determine what the reader might ask. If I anticipate questions I should answer them in the following sentences and – I know this makes me sound ancient – grammar and punctuation matter!

In addition to the handful of pages I always include two appendices, one for FAQs for questions I anticipate might be asked of the overall proposal and one to list reviewers and contributors as the document is socialised. I might also include other appendices if I need to add further evidence or examples to help people reach a conclusion.

I then circulate it to a group of people who will have knowledge around the proposed area for change, and who are most likely to be affected by any change. Once they have added comments, asked questions and/or proposed amendments we get together as a group and discuss the proposal. The outcome of that meeting should be a revised document that has the broad agreement of everyone at the meeting. Their names are added to the appendix I mentioned above before the document is given a wider audience. I then collect comments and concerns from the wider audience and again, the document can be amended – usually at this stage the alterations are minor and a new, hopefully final, version can be distributed.

By working in this way people feel part of the change. They have had a say in it and we all have a better understanding of each other’s view and have achieved at least close to a consensus. The added benefit is that the change has been discussed over a period of time and so people are already making that emotional shift to the new status quo.

Patience

Look, I know, and you know, that the bright idea you had in the shower this morning is the greatest thing since sliced bread, and will revolutionise your implementation processes overnight. You will no doubt receive a substantial pay increase, lavish praise from the CEO and a job title to impress people at dinner parties.

However, not everyone will see your wisdom instantly.  Hard to believe, I know, but there could be things about their job or the processes around it that you haven’t fully understood or even addressed.

They will need time to consider, and the opportunity to contribute, to feel they have been heard. All this takes time and all you will achieve without patience is a badly thought through change that will not endure because it was “your” idea, not “our” idea.  Which segues neatly into my third essential:

An open mind

Whenever I draft a proposal document, it is exactly that – a draft. It often undergoes substantial changes by the time the final version becomes an agreed change, and those changes come from other people, not me. I don’t have all the answers, or sometimes even all the facts. More importantly, I can never fully understand other people’s emotional responses, their values and their motivations.

The collaboration process feeds those things into the mix and the end result is better for it. When I am mentoring new managers who find delegation difficult I always tell them “Just because it has been done differently to the way you would do it doesn’t make it wrong, it might even make it better.” The same applies to introducing change; listen to and incorporate input from others. It will probably make your proposal better, and it will certainly make it enduring.

If you would like a template for the proposal document I use, including the principles and some guidance, message me with your email address and I’ll be pleased to send it to you.

Steve Syder is a Registered Project Professional, a Fellow of the APM and an RPP Assessor. He has in his time implemented Programme and Project Management practices for organisations as diverse as the UK Hydrographic Office, EDS and Orange amongst others. Until recently he was Director of Programme & Project Management at OpenBet, and he has now turned his attention to the structure and governance of the BI function at Tyche Consulting.

How to get attractive 20-somethings to invite you for coffee (and pay)

I became a freelancer back in 1992, before MS Windows had conquered the world and gas lamps were just beginning to disappear from the cobbled streets of England.

I stumbled into freelancing by accident really, wooed by a recruitment agent who waved the promise of a large amount of money at me because I had at the time a specialist skill that was in short supply and (relatively) high demand.

That agent was excellent. He knew his clients well, and had worked hard, not only to build a good relationship with them, but also to understand their business and their business needs.

I worked through no other agency for the next five years, and in the following years I worked with other agents who had a similar modus operandi.

Skip forward a decade or so and there has been a dramatic step-change in the way recruiters work, and not for the better. The true skills of a recruiting agent seem to have disappeared, to be replaced by little more than the ability to do a word search on the agency’s database, which in turn generates an automated email, usually starting with words to the effect “Please forgive me if this email is inappropriate” (it usually is) and usually ending with “If you know anyone suitable for this role please let me know.” (They would call it networking, I call it doing their job for them).

There is no relationship with client or candidate in this activity. There is no understanding of the client’s business or business needs, other than an ability to spout parrot-fashion from the company’s web site or the job spec. Many recruiters who contact me do not even understand the words they are saying.

I’ve lost count of the number who have called me about programme management and confidently asserted that “You need a Microsoft Project qualification” when the job spec had asked for MSP.

There is no attempt to match the candidates’ aspirations or requirements with this approach. On more than one occasion I’ve had a recruiter on the phone utterly astonished that I’m not about to up sticks and move to another part of the country – or even another country – purely so they can earn brownie points and commission.

Of course, there are still some good recruiters out there – the one who placed me in my current role was old-school and gave great service to me and the client alike – but so many of them are straight from university with no concept of the job being about more than matching words and firing off emails.

The other thing they do, of course, is invite you for coffee. I’d love to believe that this was a bid to get to know candidates better, but, having drunk lakes of coffee in the company of gauche twenty-somethings, I can tell you it isn’t. It’s nothing more than a box-ticking exercise for new recruits. The theory might be good but the practice is mind-numbingly time wasting. They seem not to understand the purpose of the meeting; they’ve just been told at work it’s something they must do.

I’ve yet to meet a recruitment agent under (at least) 30 who can empathise with the career and personal needs of someone my age and who has the ability to ask probing questions to understand what I offer. Mind you, it’s not just the newly graduated who are at it.

Two or three times I’ve given more experienced agents the benefit of the doubt when they have said “Oh no! I’m different. I’m keen to build relationships and understand you and the client to benefit all parties.” Off I go, drink my coffee, give it my best pitch to tell them what I think they need to know, answer their questions and swap business cards, only to never hear from them again.

Now you might think that, having met me they’ve decided I’m best avoided, and of course, I can’t be blameless. I’ve only written approximately 400 versions of my CV since 1992, and I’ve been told by people in their first job “It’s too long” and “It’s too short” in roughly equal measure. I’ve tweaked it, pimped it, preened it, added key words, removed key words and even paid a couple of times to have professional rewrites. I’ve devoted many hours to honing my personal brand via my web site, my LinkedIn profile and Twitter postings, including publishing case studies and a Prezi version of my career history, but perhaps I should have done more.

However, if anyone thinks I haven’t done enough, it begs the questions “How come I’ve been working for the last 23 years since I gave up my permanent role and why are my LinkedIn recommendations so glowing?”

What’s my conclusion? Now more than ever before job sites are a waste of time, and firing off a CV to a recruitment agency is pretty pointless. Work seldom comes to the freelancer, (s)he has to proactively find it, either by maintaining a good professional network or by targeting specific companies.

Just about every role I’ve had for at least the last decade has arisen from my personal network and/or from a decent recruiter taking the trouble to actually read my LinkedIn profile.

Meanwhile, I’m left to lament the almost complete passing of the diligent recruitment agent (diligence in that area now seems to be the exclusive preserve of head hunters) and, even more melancholy, wonder why there were not weekly occurrences of very attractive twenty-somethings saying they’d like to meet for coffee back in the day when I still had hair!

Steve Syder is a Registered Project Professional, a Fellow of the APM and an RPP Assessor. He has in his time implemented Programme and Project Management practices for organisations as diverse as the UK Hydrographic Office, EDS and Orange amongst others. Until recently he was Director of Programme & Project Management at OpenBet, and he has now turned his attention to the structure and governance of the BI function at Tyche Consulting.

Is Agile Software Development a Cul-de-sac for a PM's Career?

My starting premise is that in order to grow in a successful career as a project manager you need to acquire and practice a core range of  competencies. A good example would be those described in the Association for Project Management’s (APM) Competence Framework, which do not differ greatly from the competencies laid down by any other professional body for project managers.

With that starting point, the answer to my question must be “Yes, agile software development is a cul-de-sac for a PM’s career.”  I do not believe that, within an agile team, there is the scope for a PM to acquire and practice many of the competencies necessary to be regarded as a fully rounded PM, let alone to be able to attain Registered Project Professional (RPP) status. Ambitious Project Managers must find a wider remit if they are to grow and advance their careers.

Moving away from the theoretical to the empirical, I have yet to have first hand experience of any organisation engaged in agile software development where the PM is doing anything like the full range of activities I – and the APM – would associate with professional project management.

In almost all cases I have seen the PM is little more than an extremely competent administrator, usually reporting to a development manager. At best, the PM takes the role of Scrum Master, which I believe is a career path of its own, and a more appropriate role in agile teams.

Let’s look at some of the competencies and see if they can be practised within an agile setting. I think they fall into four groups.

First, those where it is possible to create an argument that they are used irrespective of the technique being used to deliver any piece of work:

Professionalism & Ethics. Few if any would dispute that one can behave professionally and ethically whatever the role.

Teamwork. Again, the very essence of agile is teamwork so it would be difficult to argue that the PM is not using this competence.

Behavioural characteristics. Similar to professionalism, maintaining the right behaviours would seem to be a universal requirement.

Health, safety and environmental management is another example of a universal competence, with more significance for some than others.

Second, those competencies that are demonstrably practised by Project Managers in an agile team and in my view should be the province of Scrum Masters:

Communication and Information management and reporting. Certainly. The PM is usually responsible for communicating progress, burn-down charts, user requirements and so on.

Stakeholder Management. Undoubtedly; the PM is often seen as the primary point of contact by stakeholders, and, given agile’s emphasis on people, relationships and communication over process and rules this is a competency that the PM probably exercises every working day.

Scheduling. Sort of. In a “self-managing team” prioritisation and scope for each sprint is a team effort, but the PM might be responsible for managing the backlog in consultation with stakeholders (although I would want to argue that this is, or should be, the role for the Product Owner, and the PM is little more than the scribe for the Product Owner).

Budgeting and cost management. Maybe, although I have to say at best my experience is that PMs in agile teams do nothing more than keep track of man-days required to deliver, e.g. a MVP compared to the original forecast, which is hardly the way the Competence Framework defines this competence or the way most people would understand the term.

Risk and Issue management. Probably, when they are practised at all in agile teams. The PM will keep RAID Logs but it’s a fairly solitary activity and I’m willing to bet that few developers in an agile team really feel the Log is relevant to them, unlike in a waterfall team where a clear correlation between risks and deadlines might be made.

Third, things that fall into a grey area where sophists might tie themselves in knots arguing a PM does them in an agile environment:

Conflict management. In the very loosest sense of the term we all manage some conflict as part of office life, but in a stricter interpretation of the competency, the PM might be responsible for gaining agreement between stakeholders

But would be unlikely to resolve conflict within the team – that task would probably fall to the Development Manager.

Project success and benefits management. In the sense of this competence as outlined in the APM Framework I haven’t seen PMs undertake this in an agile environment. By its very nature the environment is iterative and collaborative and it is effectively business as usual for developers to demonstrate prototypes and gain sign-off along the route. It could be argued that once the MVP is implemented PMs monitor the benefits against those anticipated in the Business Case, and for any subsequent enhancements of the product, which is why I have listed it in my third category, but it has never been my experience.

So the first three sections cover 13 of the 29 core competencies required of an RPP. The final list explains my justification for the claim that agile is a career-killer for project managers.

Leadership

In an agile software development team the PM is completely pushed out of any formal leadership. Development Managers are responsible for creating an environment to encourage high performance, gaining commitment, addressing development needs and motivating the team. The best a PM can do is to set a good example of professionalism and positivity.

PMP. Or PID if you prefer your flavour of project management to be PRINCE 2. If you really wanted to, I suppose you could argue that the PM documents why the work is being done, but in my experience this is covered off in a business case created before the PM is involved. Similarly, the PM could be said to document what is being done in maintaining the backlog, but that, more strictly is the Product Owner’s responsibility. I cannot think of a single convincing argument that the PM documents the how and when for agile software development in a self-managing team, and talk of schedules, milestones and critical path ring pretty hollow even if you do produce a Gantt chart of fortnightly sprint dates.

Change control. There is no formal change control in the sense that the Framework means it in an agile team. Talk of signing off scope then subjecting it to configuration management makes sense in the context of waterfall development but in an agile world responding to change with minimal fuss is the inevitable inference from the Agile Manifesto.

Scheduling. In conjunction with the Product Owner the PM might agree the priority of items on the backlog but when it comes to scheduling that’s the domain of the self-managing team at the sprint planning meeting.

Quality management. Again, the competence against which PMs are judged assumes a formal document stating quality expectations and approach. In agile methodology the emphasis is on people, not processes and documentation. Quality is established by prototyping and continuous, incremental improvement and this is done by collaboration between team members and stakeholders and the “Quality Log” is not “maintained”, it is implicit in each subsequent code release.

Resource management. The Development Manager, not the PM, will normally identify what resources are needed and scheduling, smoothing and levelling are meaningless for an agile team. Talk of a schedule and resource allocation plan is similarly meaningless, as is the notion of controlling resources with respect to scope changes.

Project life cycles. The life cycle model is, by definition, agile, and evaluation and approval points are inherent in the sprint process, so there is nothing meaningful for the PM to do against this competency.

Organisational roles. You might well ask “What OBS?”. It’s a self-managing small team, with the emphasis on collaboration, not documentation.

Governance of project management. Any adherence to the organisation’s processes, standards and guidelines is self-governing in a high-performing agile team, and in a lesser performing one is enforced by the Development Manager. In any event it is more likely to be technical than governance in nature.

Project reviews. Most of this competency is business as usual for an agile team, holding scrums/daily stand-ups and demonstrating prototypes. At best, a PM might organise a Post-Project Evaluation and create a Lessons Learned Log.

Scope management. Product Breakdown Structure? Change Control Process? I think not. Requirements and objectives are determined by the business, usually documented by the Product Owner and held in a backlog to be added to sprints as the team sees fit.

Requirements management. See “Scope management” and “Project reviews” above. Why would you need a PM to document requirements when you have a Product Owner, Development Manager and team of developers all talking to each other and collaborating?

Estimating. In an agile team this activity is reduced to calculating the team velocity, easily and quickly done by the Development Manager in agreement with the Product Owner. As a side note, this produces far better estimates than the methods used for a waterfall project where, despite a wealth of experience to the contrary, stakeholders demand and PMs strive for delivery certainty.

Business case. This is an activity that falls squarely on the shoulders of the Product Owner, who should be a subject-matter expert on the business trends and benefits of what the team is developing.

Organisation structure. Typically, Development Managers will agree amongst themselves when resources need to move from one team to another for a given piece of work. That’s an inevitable (healthy) cultural consequence of self-governing, collaborative teams.

Negotiation. Let’s be honest. Negotiation for a PM on an agile team might involve agreeing different priorities for the backlog with a Product Owner but there is likely to be little else. There would certainly be no opportunity to negotiate contracts and the like, creating a negotiation strategy as envisaged by the competency.

So I started out by asserting that Project Managers, embedded in purely agile software development teams are damaging their careers because they can never be fully engaged, if at all, in many of the activities regarded as core to professional project management bodies. Of the APM’s 29 core competencies, four are done by just about everybody, seven are done by PMs in agile teams (I’ve conjoined some) and I think they would be more appropriately given to a scrum master, two you might be able to make a case for but possibly not whilst keeping a straight face, and sixteen are not done in any meaningful way by PMs in agile teams.

I’ve no doubt that people making a living selling books and training courses on “Project Management in an Agile World” or similar will leap to tell me I’m wrong, and I’ll do my utmost to keep an open mind as I read what they say, but the whiff of vested interest will make it hard for me to suppress my cynicism.

Similarly, there might be Project Managers out there doing a great job in agile teams who take issue with my assessment. I would suggest that they complete the APM RPP Portfolio of Evidence and see if they have convinced themselves. If you have, I’d love to see it. If you haven’t, I suggest you either decide to go down the Scrum Master route or consider a change of job for the benefit of your project management career.

Steve Syder is a Registered Project Professional, a Fellow of the APM and an RPP Assessor. He has in his time implemented Programme and Project Management practices for organisations as diverse as the UK Hydrographic Office, EDS and Orange amongst others. Until recently he was Director of Project Management at OpenBet, and he has now turned his attention to governance of the BI function at Tyche Consulting, where he encourages an agile approach.