He should have been buzzing but instead told me how, not only had he not lost weight this month, he’d actually gained a little and so was really cross with himself!
As he raised his hand to ask for the bill I couldn’t help noticing how big his biceps were!!! I couldn’t help thinking that any weight he had put on must be muscle!
This weight gain though wasn’t the only reason why he was beating himself up. That morning, at work he had had a mauling from his Sales Director because he wasn’t hitting his targets. In fact, no-one in his team was anywhere near target and across his industry as a whole, sales were down both quarter on quarter and year on year.
And then, after delivering this gloomy summary of his work life he told me that his accounts had actually brought in more money than the last quarter and his figures were up year on year too. In fact, he’d already beaten his sales for the last 12 months in just nine months of this year.
Wait! What!! He was bucking the industry trend; he was outperforming his colleagues and his competitors, and he had brought in more money than last year already! AND he’d had to sit in a meeting where his boss told him that this made him a failure???
So, what’s this got to do with IT Project Management?
It’s all about choosing the right metrics for success.
Let’s reframe both of these stories.
Needing new trousers because he’d lost inches around his waist, bulging biceps, looking ten years younger, having more energy, a slimmer face … these sound like success to me, but because he was measuring his weight, he felt he was failing. Even using that metric, the data is subjective, muscle weighs more than fat so, given the other evidence, a few pounds gained is a success!
Then at work, he’s overperforming in a down market. He’s achieving greater results than last year, in a shorter time and, taking his quarter on quarter results as a yardstick, he is trending in an upward direction. Again, this all sounds like success in my book. However, because his sales director set arbitrarily high targets, he and his colleagues feel like failures when they should be popping champagne corks.
And WE do it all the time in IT Project Management.
A consultant friend is working with a failing project team right now. He was called in to help turn things around and actually solved their problem in one afternoon!
The team is producing some cutting edge, market-disrupting software. Competitors are following where this team leads, my friend, says that the creative vibe reminds him of what Apple must have been like during the heights of Steve Jobs reign. Imagine that! But the team is failing?
It IS ‘failing’ based on two key measures, delivery date and cost.
OK – they’re quite big failure red flags and they are among the most common causes of IT project fatality so on that first afternoon my friend drilled down.
Yes, the projects were always delivered late but it was because of scope creep. Wait! Another red flag – wow! These guys really are failures!!! No, they’re not! Here’s the thing. As the market changed the team would adapt their project, ensuring that they delivered an end product that was in tune with business need on the delivery date rather than business need when the project was greenlighted – often two different things.
Also, they would listen to end-user and stakeholder feedback along the way and often, when possible, tweak the project to accommodate appropriate requests.
Lastly, they were very keen on delivering bug-free software – their mantra was better to test the software before launch than test the patience of the end-user afterwards. All of this had the effect of delaying projects and, sometimes, it also increased costs.
“To make this project team successful in terms of cost and delivery date,” my friend said to the board on that first afternoon, “from tomorrow we can ban scope creep from projects’ lifecycles altogether.”
“Of course, this means that in future, innovations might have to wait.”
He then listed a bunch of the ‘failures’ that the team had delivered that weren’t in the original project brief and that had delivered revenue, growth and market share, and he catalogued all the market-disrupting ideas that had been accommodated ‘mid-life-cycle’.
He tells the story of how the board seemed to collectively squirm at this thought.
“Or,” he said, “we could recalibrate what we call success, build some contingency funding into project budgets and cut them some slack on time horizons.”
They agreed to do that.
Now, I’m not for one minute saying that time and cost are not important metrics for success. Of course, they are … but this team was succeeding in terms of leading massive business change and growth. The projects they manage are delivering business value time and again. Recall how my friend considers them – “what Apple must have been like during the heights of Steve Jobs reign”. They don’t sound like failures, do they?
The funny thing is, this same project team is still delivering projects within the same time frames and their projects are still costing the same as they did before my friend intervened. The only difference is that they are now considered to be successful. And guess what has happened to morale?
Another thing about failure, that this team and most project teams I work with do, is they learn from ‘failure’. If failure teaches you vital lessons that you take into your next project or team – is it really failure at all? Google’s ‘moonshot factory’ X is set up to expedite failure. You tell Astro Teller at X that his teams are failing he’d probably high five you, hug you and thank you for the compliment.
Sometimes we just set our failure radar wrong. Like when we kick ourselves for gaining weight (that is muscle and makes us look like a beefcake) or when we berate our team for not hitting unachievable, illogical and random sales targets that we set for them.
I suppose what I’m saying is, perhaps we should start to question what we consider success to be. Redefine it in terms that are actually relevant to the climate in which we operate. If time isn’t an issue, then a project hasn’t failed if it’s delivered a week later than it was due on paper. Is it?
When I look at the repeatedly high failure rates for IT Projects, I do wonder whether we are failing because we are setting ourselves up to fail.
I always think a fresh look at your whole portfolio helps assess whether you are applying the right metrics for success and a fresh pair of independent eyes can often see truths that are hidden from you, working in and on your projects day in, day out.
So, take another look at that failing project but with more objective eyes. What’s the end goal that you want to achieve? Is the project really failing when measured against this or is it failing based on criteria that aren’t fit for purpose? Taking a helicopter view and re-evaluating our metrics for success can have a really positive impact across the portfolio – you may identify resources you can buy in from the Project Management as a Service market or you may just decide to give yourself a break, ease the pressure and crack on delivering the business change you set out to achieve.
My metric for success on this article is that it sparks debate, encourages a rethink on what failure actually is and gives us all some breathing space to allow creative thinking and solutions to flow. I’d love to hear from you, especially if that failing project could indeed do with a fresh pair of independent, impartial and objective eyes.
Find out more about Project Management as a Service from Stoneseed
"What's going wrong?"
Both these questions were asked by different Project Managers leading IT Projects that were failing this year. Both had identified issues, both were keen to sort those issues out, both held almost identical team meetings to address the challenges.
One was more successful than the other.
The first Project Manager, who framed the question in terms of looking for improvements, was the more successful of the two.
They are both seeking the same outcome, the question is essentially the same - let's identify what isn't working and make it work! So why did they get different results?
I believe that it is down to the wording of the question. Look at how the second question focusses on the failures. Sure, identifying that your issue is scope creep will prompt you to sort out your scope creep, but not before the team has beaten itself up over the fact that you have failed to keep control of your scope. Shining a bright light on the problem rather than what you can do to avoid similar banana skins in the future can limit your potential.
The first question is much more positive. You may have scope creep issues but, by asking the question this way, you immediately open up a solution space. The answer is more likely to be that you'll say 'no' to scope changes or, at least, set up robust mechanisms for reviewing requests and communicating expected consequences to stakeholders.
And yet, the more negative question style is more common in debriefs after failed IT Projects and so teams may not be getting the best out of this time investment.
How you talk to yourself is very important! But where does all this negativity come from? Are we programmed this way?
In his book, What To Say When You Talk To Yourself", Shad Helmstetter talks of the 148,000 "No's" that you will most likely have heard before your 18th birthday. Whether it's your parents trying to protect you or your teacher or community leaders trying to keep you heading in the right direction, you heard "no" a lot as you were growing up. Compare that to the number of times you were told how much you could achieve, what you could accomplish and it's easy to understand how these negative thought and language patterns dominate. Helmstetter claims that "leading behavioural researchers have told us that as much as seventy-five per cent of everything we think is negative, counterproductive, and works against us."
So, it is in our programming! But here's the thing. We work in IT, if anyone should be great at reprogramming, it is US!
You'll have heard of NLP.
NLP, short for neuro-linguistic programming, can be used for personal development, phobias, and anxiety. NLP uses perceptual, behavioural, and communication techniques to make it easier for you to change your thoughts and actions. Many successful sports coaches, world champions, swear by it! My Project Manager friend Karen does too!
"NLP will help you map out your view of the world, and because they will be different, understand the maps of others. NLP can help you to understand the programming behind your thought processes. It makes you more self-aware," she wrote to me recently.
Self-awareness may be the key.
The author of NLP for Project Managers: Make Things Happen with Neuro-Linguistic Programming, Dr Peter Parkes, carried out a poll and self-awareness was the number one behaviour trait that stakeholders wished that their Project Managers had. Karen says, "If you're not self-aware if you don't understand yourself, what makes you tick, then how can you even hope to understand and motivate your team."
Since finding NLP, Karen believes that communicating with and motivating her team has vastly improved. "NLP taught me that our world view will be dominated by our senses, in an IT Project, we will either see, hear or feel a problem, for example. If you listen to your team, really listen to the language they use and reflect their world view in your communications - you open up a new level of trust and understanding. I have a team member who will say, 'I don't like the look of this.' Another might say 'This doesn't feel right,' and another will express disbelief at what they are ‘hearing’ - but they might all be describing the same issue. In NLP these preferences are referred to as “Visual”, “Auditory”, and “Kinesthetic”. If you choose the wrong language your communication might not be as effective. Saying 'let's see what our best options are' to a team member with auditory preference might not hit the target as well as 'which of these options sounds best' - it sounds daft, but it works!"
Another of my Project Manager friends, Stefan has a team driven by feelings, they are all “kinesthetic”. Stefan has a "How It Will Feel When It's Done" list. Now, you may have a "To-Do Today" schedule or a "Task List" - how inspiring are they? Stefan identified that a cold list of "stuff" that needed doing didn't excite him or his team, tasks were met with little enthusiasm and often milestones would either be completed only just on time or late.
"The problem was how we were presenting our own workload to ourselves; it was dull and left us flat. So we started to think how we would feel when each task had been completed. Attaching a positive feeling to even the most mundane task suddenly made it a worthy mission. We'd be excited! If another team was depending our task delivering on time, we'd imagine their gratitude, we'd visualise the business change that our work was about to facilitate, imagine the end user experience that we were enhancing."
Another project team I worked with last year has banned 'need to', 'have to' and 'must do' from their language. Carl, the PM, told me, "Expressing tasks in this way makes them chores! You need to clean the bathroom, or you must do the hoovering! Doesn't get you revved up, does it? When approaching our tasks 'we want to' do them. Especially in the more grey performance/monitoring stage of a project and the more difficult project close phase, it's amazing the difference that 'wanting to' rather than 'having to' makes!"
How you talk to yourself is so important! That little voice is running a commentary on your life all the time. It is influencing your thinking and creating outcomes for your IT Project, usually without you even knowing. It's like having a coach in your ear all the time. Try to catch and correct yourself when negative language patterns dominate your communications.
So, in conclusion, mind your language!
AND get in touch! How can we make things better in your IT Project World?
What To Say When You Talk To Yourself – Shad Helmsetter, Grindle Press 1986
NLP for Project Managers: Make Things Happen with Neuro-Linguistic Programming - Peter Parkes, BCS (11 Mar. 2011)
May 2019 sees the fifth, annual 'Women in Tech Festival' in Silicon Valley. Aptly, my invitation to attend dropped into my inbox at the same time as a reply to a question that I'd asked a CIO friend whose organisation has consistently high IT project delivery success rates.
I had asked this CIO for the secret to their success.
"The women on our team," was the reply.
To be honest, at first, I thought that this was a glib remark about 'ability to multi-task' or a cliched observation about 'bossiness, pushing tasks through'. In fact, it was a genuine, firmly held belief that the team's output had improved as the gender mix had evened out. More than a belief actually, the results clearly prove it: success rates improved as more women joined the team.
Coincidence? Is there any evidence that women make better project managers? Sort of! Back in 2007, a survey of U.S. project managers revealed that female PMs outperformed male PMs in key areas and that women PMs abandoned fewer projects than their male counterparts.
But do women really make better project managers or does a more diverse mix just make for a better team? And what do you do if there are gaps of any kind within your team?
The tech gender split hasn't always been like this. Women once made up 80% of the computer industry. These days less than 20% are women and my own experience tells me that, in IT Project Management, the male/female split is around this mark too. Indeed, in 2015, it was estimated that somewhere between just 17 and 30% per cent of project managers were women.
A brief history of women in Tech and the greatest IT Project EVER.
I suppose it started with Bletchley Park which I once heard a radio announcer call "the greatest IT Project ever". The work done there shortened the second world war by months and saved between 14 and 21 million lives, so when I compare these deliverables to some of the ones I stress over these days, I think "the greatest IT Project ever" is about right!! Although it is the men, like Alan Turing, who often are remembered, around 8,000 women were employed there during World War II and, rightly, in recent years, it is the women of Bletchley Park have had their work recognised. Various books, TV documentaries and the ITV drama 'The Bletchley Circle' have celebrated them and David Kenyon, research historian at Bletchley Park Trust said: “Bletchley Park could not have functioned without its female employees”.
The computer industry workforce remained largely female dominated for decades, most of the early coders were women and jobs in the tech industry were seen as clerical functions.
Marie Hicks, a British tech industry historian, talking on BBC radio programme "Jobs For The Boys" says, "In the early days, it hadn't yet professionalised, there was this idea that it was rote, and women were paid less, so girl hours were obviously cheaper than man-hours."
However, things started to change as emphasis switched to the potential power of the tech jobs. As Marie Hicks explains, "You got to lay out the system that was going to be used to help make the government-run or help make a bank run or help make an insurance company run." Suddenly there were exciting career paths available and the men started to get interested.
Women increasingly found it harder to be heard higher up in tech circles. Tech entrepreneur Dame Stephanie Shirley had to adopt her family nickname "Steve" to be taken seriously! Her tech company would one day employ over 8,000 people, a similar number to those working at Bletchley Park.
Women for decades reported a culture of harassment and techno-chauvinism even within global tech giants.
And that's how we find ourselves where we are today, as I say, somewhere between 17–30% per cent of project managers are women.
So, let's let that sink in:
a) women are great at delivering IT Projects;
b) less than 30% (actually probably less than 20%) of project managers are women;
c) IT Project failure rates remain high.
I can't help wondering if, as an industry, we may be missing something here.
I asked for some feedback from clients, colleagues and friends. Women seemed to have greater strengths in four key areas and this anecdotal evidence can be backed up with various studies.
A) Interpersonal and non-verbal communication – both key skills for project managers. "An examination of gender differences in managerial communication of project managers" claimed that women tended to have greater strengths than men in this area. (Snyder D., McLaurin J. R., Little B. & Taylor R., 1996)
B) Client Relations - "Clients and stakeholders take bad news from me better than my male colleagues (who have had some right stand up rows)," a female PM messaged me. In fact, Nath’s (2000) research with project managers showed that that being a woman made it easier to gain access to clients, women got on better with clients, and clients were more willing to talk to women than men, and more willing to take bad news from women.
C) Teamwork - A UK study of women project managers concluded that "women have significantly more of a team management style than do men, characterized by a high regard for people and high regard for task, they are less traditional and more visionary in their approach to business, and they may have a more heightened sense of awareness and a greater sense of cultural incongruence and gender exclusion’.
D) Empathy - Women do seem more sensitive, caring and empathetic to their staff than men. There is evidence to support too, these women are "more sensitive in caring for staff and showing concern than males. They are more capable in interpreting problems and bringing order to their area and are better able to maintain tight control." One message I received read, "When I was on leave following a bereavement, I got two communications from work. Flowers from a female project manager and a text asking a project related question from a senior male project leader."
So, do women make better project leaders? I diplomatically answer this by saying that ‘great project leaders make great project leaders’, I.e., it doesn't matter whether you are a man or a woman if you've got it - you've got it.
I think it's a balance of different views, experiences and insights that creates great teams, not which loo you use.
That said, Silicon Valley Forum’s annual Women in Tech Festival celebrates women in IT, STEM, and business careers who work to inspire, engage, and empower other women and I'm a huge fan. So, perhaps it's time we gave similar focus to women in our specific part of the tech ecosystem.
The benefits are there for all to see.
It's an exciting time to be a BA but some businesses are not benefitting from the expanded potential. Either their BA hasn't adapted in this direction, or the business processes are too rigid to allow role evolution, or perhaps (as is often still the case) they haven't got an IT Business Analyst at all. The IT Project Management services sector is geared up and ready to help with all these scenarios and more.
Here Are Five Examples Of The Rising Value of The IT Business Analyst (or things that could be added to the job spec!)
1 - Defender of Business Case Alignment
Often client/stakeholder requirements are prioritised as hot or lukewarm, but these priorities can be based on perception and personal agenda, rather than real business impact. The real danger here is that unchallenged, this can cause an IT Project to veer off course and not deliver intended business benefits. A good BA realises when this happens and therefore keeps the project focused on business case, filtering the requirements against strategic objectives and driving results that benefit the business as a whole.
A CIO colleague puts it, "A good BA is plugged into the whole matrix! They understand the project's relevance in relation to business objectives and display a passion and tenacity for keeping them aligned. Great BAs actually save organisations time, money and wasted resources"
2 - Improver Of Business Process
BAs are stepping beyond their traditional role of simply evaluating the value of IT to the business. More and more, BAs are evaluating the actual business process at their organisation, that is they are assessing the very thing that drives the need for the IT Project in the first place. As their understanding grows, they are better placed to not only help manage change after delivery into service but actually help shape business process against best practice, cutting edge IT. A real WIN/WIN for the organisation.
3 - Strategic Thought Leaders
BAs are also getting involved earlier at the stage when thoughts about IT investment are being formed and decisions are being taken. This makes sense, BAs have shown their value in tactical operational areas and these skills are instantly transferable to the more strategic design stage of IT Project Portfolios.
BAs I know who operate in this way grow their influence within the organisation and many have become a conduit through which most business functions flow.
4 - Multi-Project Specialists
I think that it fair to say that many Business Analysts still work on one project or one system at a time and while this may be down to scope and scale or less confidence in the robustness of systems, it could also just be down to a failure to evolve.
Increased use of agile processes, fewer larger scope projects and better breaking down into 'chunks', more robust "off the shelf" solutions are all giving Business Analysts space and freedom to handle more projects at a time. BAs working this way are delivering savings not just in how IT Projects function but also how they themselves operate.
5 - Multi-System Competencies
Traditional IT systems were built to deliver a single business need. So businesses would end up with several siloed IT systems all delivering different requirements. Many did not talk to each other and as they were often bespoke and expensive - businesses were loathed to replace them.
The growth in commercial off-the-shelf (COTS) software packages changed this. Solutions which are bought off the shelf and then adapted to satisfy the needs of the purchasing organisation are cheaper than commissioning traditional custom-made, or bespoke, solutions - so businesses are filling their shopping baskets! The real skill here is making them work together and this is an area where BAs are really delivering value.
A good example recently was a business that introduced a new IT system for generating delivery notes. The Transport Director wanted a new automated system to improve on the existing (and rather quaint) heritage software package that still even required the end user to generate delivery note numbers "by hand" and write them in a lined A4 book!
Traditional BAs would have worked on this system and this business need would have been delivered but the hero BA at this organisation saw the potential in linking the new delivery notes software with other departments. Sales administrators now get a real-time delivery eta to pass to customers; the delivery note system automatically adjusts stock levels for the store controller to keep on top of inventory and alerts purchasing when levels are low; and it automatically advises the accounts department the moment a delivery is made so that an invoice can be raised and emailed reducing time from delivery to account settlement.
6 - Cross Department Competencies
A natural step on from all of the above is the expansion of departmental stakeholder groups who increasingly rely upon support from IT Business Analysts. The best BAs are driving this by using their knowledge of business processes and weighing up the cross-departmental impact of every IT Project.
These BAs are becoming adept at understanding and prioritising the competing needs of various departments, they are improving their communication skills and again their circle of influence within their business structure is growing.
For years, I've said that rather than just supporting the business, in most firms IT now IS the business - so who better to have at the heart of this than an IT Business Analyst.
In conclusion, although the job title remains unchanged, the role of the Business Analyst is evolving all the time. Business Analysts that have adapted in this direction are delivering greater results and a competitive edge to their organisations.
Businesses that do not have such a character on their payroll may be missing out but can access talent like this from a trusted external resource provider. As IT becomes increasingly driven by return on investment, to not do so could be handing your competition a commercial advantage that may come back to bite you hard.
The reasons that project teams ask for help are manyfold, sometimes the project is more complex than the client's in-house capability and experience, at other times a stretched portfolio requires more resources and then at other times a client may have no in-house facility and need end to end Project Management Office services.
Then .... there are the emergency cases.
There have been many surveys and studies on how many projects fail over the years and they have pretty much all been above the 50% mark. Imagine if over half of trains were late, or over half of hospital patients didn't survive operations, or over a season Manchester United lost over half of their games, actually that last one is a bad example right now, but you get my point. Questions would be asked in any other industry facing such failure rates.
We took a look at the reasons behind many of the emergency calls that we had received, and a trend started to emerge, they seemed to fall into two main categories.
Planning and Proactivity. As with most project problems potential solutions are available in the Project Management as a Service market, more on that later but first let's drill down a little deeper.
Let's start with ...
1 - Planning ...
"Proper Preparation Prevents Poor Performance" (and slightly more colourful variations of this) has become a bit of a business cliché over the years.
Despite this, many projects are starting without the necessary level of planning.
Often, projects are started too quickly because of well-intentioned over excitement. Let's face it, when you have pitched an idea that you are passionate about and you get the green light - it is understandable that you want to crack on as a soon as possible. Subsequently, we are seeing projects run aground later because the planning phase was rushed, and not enough consideration was given to risk or any potential issues or concerns, in a recent case, even concerns that were flagged up by a client were overlooked by a project team who rushed at their project like an over-enthusiastic Labrador puppy! In these times of increasing complexity, it is more and more essential that teams put proper care into the planning phase.
Before we lay all the blame at the project team's door, clients can have a hand in disrupting the planning stage too. In a recent case, a client's over-reliance on their project partner caused problems as both service provider and client assumed that each other was asking the right questions to plan for any challenges that might occur.
In another, the client had not initiated an IT Project for a long time and assumed that the project was within the capability of their in-house team, the team was rusty, and the new project was more complex than previous ones. They soon reached out for help but not until after the project had started - proper planning would have flagged these potential concerns ahead of them becoming a real-time problem.
Then, there is the "figure it out later" brigade.
As a fervent planner, I always used to have a reluctant admiration for project managers and teams who seemed able to fly 'by the seat of their pants' through a project. As Projects have become more complex and increasingly business case linked though, these types of PMs are enjoying fewer successes. To leverage the maximum benefit from a project you really have to have deliverables and milestones clear in your mind before you start. The days of knowing what the end result will look like and then filling in the middle as you go along are confined to history. Ironically, even former 'seat of pants' project managers are finding that by having crystal clear objectives, properly allocated resources, realistic timelines and projects that are planned in manageable, properly delegated chunks of work, they have more freedom to improvise responses, rather than less.
2 - Proactivity
Far too many projects are failing because the teams leading them are reactive rather than proactive. This follows on nicely from the part about flying by the 'seat of your pants' because the other discipline that these project types need to learn is the art of defining risks before a project starts. I read somewhere that this is the cause of about a third of project fails, certainly anecdotally when we are asked to rescue a project, it is often the undefined risks that have broadsided teams.
Contingency planning is key to the success of a project and the more experience you have, the more you start to see patterns emerge in the things that can hamper even a well-planned IT project.
A friend told me about how she and her team were working on a project that had hit challenges because the regulatory landscape for their industry changed and the project, as scheduled for delivery, would no longer be compliant. I think that she was expecting sympathy, and as a friend, I gave her some, but as a fellow project professional, I wondered how long the regulatory changes had taken to pass through parliament and whether she could have realistically anticipated them. Indeed, the white paper on the subject predated the planning stage for the project so there really wasn't any excuse.
As, a kid I remember seeing a darts player, John Lowe, interviewed after a match he'd won. Before he threw the winning dart his two previous arrows had hit the wire and bounced onto the floor drawing gasps from the crowd. His opponent also had a potential three dart finish, had he been allowed to step up, so the pressure was on. That third dart had to count! Lowe calmly threw the dart, it hit the target and he won the match. Afterwards, the interviewer asked how he had maintained his composure with the previous two attempts rebounding onto the floor and Lowe said, "I never look at the dart on the ground." I've never forgotten that - he had a proactive plan. A dart hitting the wire and landing on the stage is paradoxically both unlikely and likely in equal measure but so are many of the things that can derail an IT Project. It’s your preparedness to respond that can make all the difference.
The point is, anticipating problems and knowing how you will respond is a great skill, a skill that you get better at the more experience you have, and which gets easier the more thorough your planning stage is. That's where the third P of the pack comes in - PMaaS. The Project Management as a Service market has resources from single talent to end to end Project Management Office to help fill planning or proactivity gaps or whatever capability issue you encounter. The more flexible PMaaS partners allow you to dial up and dial down the resource you hire in sync with your needs at any given time.
Project failure rates are still worryingly high but with a universe of PMaaS resources available and proper planning and a more proactive outlook, the industry has a real opportunity to put things right - it is within our power. I just wish we could do something about Manchester United!
After a few minutes, Liz asked Steve, "So, what do you do?"
What would you have said in answer to that?
If like me, your default response is to say, "I'm a Professional Services Director" (or whatever your job title happens to be) then Steve's answer may surprise you. What Steve said was a little unconventional and it made me think.
So ... Steve didn't say, "I'm an IT Project Manager". Although, he is.
He said, "I'm a Dad of three, I run, cycle and swim and I'm an IT Project Manager."
Liz and Steve then had a conversation about parenthood and how Liz used to swim for the school and county teams, Steve said he did too. It was like they'd known each other for years! I struggled to get a word in edgeways!
After Liz had left I talked with Steve about his response and he told me that for years he too had trotted out that same answer that you and I would have given. It had often led him down something of a conversational cul-de-sac. If the person he was talking with was interested in IT Project Management they would have a great chat, but if they weren't, then what followed was rather awkward.
"And anyway," said Steve, "she asked what I do. I do more than manage IT projects!"
He's right, of course. Yet we all answer this question in this manner. We all define ourselves and each other by our jobs but we are all so much more. I started to wonder whether Steve might actually be onto something and if by defining ourselves in this way we limit our capabilities when doing the job.
Think about this. Is there something that you do in your spare time that could be a great asset to you and your project management team? Could your hobby be your unique IT Project delivery secret weapon?
I asked a few project management contacts and it quickly became clear that everyone has something that they could (and should) be bringing to the party.Here's my favourite seven!1 - The creatives! Sal is a painter, Alli bakes the most wonderful cakes from scratch and Bex can make a piano talk! They are all incredibly creative and, let's face it, often as a Project Manager - you need to be. Creative minds are great at reframing problems and imagining solutions that seem to come from nowhere! Bex's dedication to her piano playing also shows a keen sense for attention to detail - I've never heard her play a "bum note".
You are much more than your job title! By not bringing all of you to work, could you, your project team and your employer be missing out?
So, let me ask you again - what DO you do??
My epiphany came last Christmas when I asked a family member why, having peeled the sprouts, she was now cutting a little cross into the base of each one. Her answer was, "I don't know, it's just what my Mum always did."
We Googled it and it turns out there is no benefit to the cooking or the taste of sprouts by doing this, in fact, it can waterlog them! Generation after generation have done it because their parents or grandparents did too!
A great example of a dysfunctional belief, quite harmless, and it got me thinking.
Could there be dysfunctional beliefs in IT Project Management and could their impact be a little more serious than some soggy sprouts?
It turned that there were, and they were acting like a fog that could envelop IT Projects. I decided that, in future, I would challenge pre-conceived notions about how things should, or shouldn't be done, and attempt to clear the haze. Get in touch if you have busted any myths yourself, for now though, here are just ...
... 7 Dysfunctional Beliefs of IT Project Management
1 - Scope Creep Is Fatal
An IT Project where the scope doesn't change mid-lifecycle is a rarity these days. It doesn't have to always be a red flag for trouble or impending project failure, in fact, thinking back to projects I've been involved with recently, scope changes can actually be the catalyst for improved delivery.
It's how you manage scope change that is key and I guess that comes down to how well you're set up to manage it. Projects that anticipate scope changes (or see them as potentially positive) enjoy better results than projects that have a blinkered view or don't expect any change. Knowing when to allow scope change and knowing the direction of travel for your project after a scope change are key to riding it out.
2 - Hiring a Seasoned Project Manager Is Always Better Than A Less Experienced One
There was an advertisement for an IT Project Manager job in London last year that specified that the ideal candidate would have "at least five years’ experience". The inference being that a newly
qualified PM, for instance, might not be up to the job. OK, experience is a good hiring criteria but it's not the only one. Attitude, education, training, an individual's approach to managing projects, how well they fit the team or are aligned with your company culture are all really useful indicators too.
Furthermore, experience is subjective and to measure it just by time spent in the job may not be the most effective path to tread. Tom has ten years IT Project Management experience, whereas Jerry has three ... who would you hire? Tom, right? What if you discovered that Jerry had a 100% success rate during that three years and Tom had been in charge of a couple of projects that had failed during his decade? Suddenly, Jerry's the man ... right?! BUT Tom would probably have learned a lot from those failures and Jerry is probably due a howler ... yes ... but Jerry has a fresh perspective and no baggage ... you can see how experience is in the eye of the beholder?
The above, by the way, is based on actual recruitment conversation I once heard (although the candidates weren't called Tom and Jerry). ‘Jerry’ got the job and five years on still has a 100% delivery success rate.
Some projects benefit from a fresh set of eyes, a fresh perspective - don't rob your project of potentially greater success by only ever hiring the manager with the most years on the clock.
3 - Hard Data Always Beats Intuition
A huge project management dysfunctional belief is that hard facts, figures and multi-coloured spreadsheets are the only criteria upon which to base decisions and strategy. Of course, they are all vital but, alongside all those charts and information, a healthy dose of good old-fashioned human intuition can really benefit IT Project success.
One of my colleagues often reminds me that IT project delivery is all about people, end users, stakeholders, project team members, etc, and while Excel is great for monitoring data, people don't always fit that neatly into a spreadsheet cell.
In addition to this, data only comes to life when it is interpreted. Different perspectives, conclusions and insights, from human beings, add colour to decision making and strategy formation.
4 - The Client Is Always Right and Knows What They Want From The Project
A regular misconception is that clients and stakeholders know what they want.
Usually, they have a firm grip on what they are hoping to achieve and how it is aligned with business case. However, rarely do they have a complete idea of how realistic their ambition is against project budgets and delivery timescales, nor do they usually know what you will actually need to do to deliver their vision. I consulted on a struggling project a few years back that had such contradictory stakeholder goals that, in trying to deliver them all, the project team was tying itself in knots!
As a Project Manager, you need to be super focused on your client's requirements, know what they want (even when they don't!) and communicate it back in a way that they understand so that they can agree. It is very easy to deliver a project that you think ticks every box and find that, in reality, it missed ticking most.
5 - What Worked Then Will Work Again
I recall a failing project that we were called in to help once that was, at first, a bit of a head-scratcher. The budgets seemed well planned, resources were well allocated, the team had the
knowledge and experience to deliver, business case and culture were aligned. At first glance it was solid, on further investigation it turned out that the project template being used had been used before ... admittedly, with great success ... but that was then.
Past glory is never a guarantee for future success. Often the methodology, tools and resources that made one project a hit do not translate onto the next one.
I think it's like using a map that you used to drive into town ten years ago before the bypass and the roundabout with the McDonalds on it were built. Like an old map, a previous template doesn't necessarily describe the landscape you are travelling through now and it's easy to get lost.
In this case, the project team had planned well and were executing based on the plan perfectly but the new project had subtle differences that were enough to render the old template redundant.
6 - Attend To The Details Above All Else
Attention to detail matters, of course, it does. Often it's those little details, executed well, that deliver great success.
IT Project Leaders need to be careful though that they are not too zoomed in on them that they take their eye off the bigger picture, for instance, business case alignment.
I would challenge what I once heard a CIO say to a Project Manager. The PM was questioning the project's alignment with current market need but was told that this was out of both their "circles of concern". In other words, we've been commissioned to deliver X, Y and Z and if they are no longer congruent with business case then that's someone else's problem.
“The business” pays all our wages and in the same way that a marketing or sales strategy needs to be in line with business needs, so too does an IT Project, otherwise what's the point?
So sure, zoom in on the details but also zoom out once in a while and take a helicopter view of your project and where and how it fits.
7 - Any Project Manager Can Successfully Deliver Any Project
Like the templates mentioned above, Project Managers are not always transferrable. Just because Tom delivered his last project successfully, that doesn't mean you're guaranteed a happy ending with the next one. PMs are a bit like snowflakes, no two are the same!
Tom might have the same training and certificates on his wall as Jerry but just as each project is different, so is each project manager. Different talent brings different skill sets, experience, attitudes, vision, insights.
It's all about matching your resources with the needs of the Project and that can take an honest appraisal of both. Often a fresh pair of eyes is best placed to do this, an independent project management office analysis can help shine a light on any gaps. There's no shame in recognising that your brilliant team lacks certain capabilities and the Project Management as a Service market is ready to provide complementary talent and resources.
In conclusion, recognising project management dysfunctional beliefs is a really healthy thing to do, attending to them and actively working towards dispelling and destroying them could actually save your project from harm. And ... do you know what? It's really liberating. When you realise that you've been working under a fog of misconception you are set free to succeed.
Once that haze lifts, your best practice can shine through.
Find out more about Project Management as a Service
Looking beyond the rather overblown spectacle of the ceremonies themselves, there are actually some great IT Project Management lessons to be learned.
1 - It Doesn’t Always Take A Big Budget And Traditional Methodology To Succeed
I remember thinking this when "Dallas Buyers Club" got 6 nominations in 2014 including Best Picture, Best Original Screenplay, Best Actor and Best Supporting Actor. It won 3 of them, Matthew McConaughey and Jared Leto took home the actor gongs but, more interestingly, the film won Best Makeup and Hairstyling.
The makeup budget was only $250.
Perhaps the best Oscars illustration of "It Doesn’t Always Take A Big Budget" is to compare the budgets of the most recent Best Picture winner (Moonlight) and arguably the most expensive winner, from 1998, Titanic. A Reddit user, Joe Falchetto, recently adjusted the budgets of the last 50 years worth of best pictures for inflation and the chart he produced is astonishing - Titanic cost $200m (about $302.6m in today's money) - Moonlight cost just $4 million.
Similarly, IT Project success doesn't have to come at a high price. Oftentimes, a cutting-edge, targeted, Project Management as a Service solution can cost less, for example, than using in-house talent who can then be better deployed elsewhere across your portfolio and gap analysis can help you measure your resources against your ambition.
A Project Management analysis can identify ways to work cheaper and smarter with the same or better results - "Dallas Buyer's Club" was made on a budget of $5m, in less than a month, using only natural lighting!
2 - Relevance Is Key
I remember Braveheart winning Best Picture in the mid-90s, beating Apollo 13 which many people thought would win it. I have seen both movies recently and Mel Gibson's Scottish accent has not stood the test of time as well as Tom Hanks' "Houston, we have a problem". If the two movies were released today, the latter would still be worthy of a nomination, the former ... possibly not.
I saw Braveheart back in the 90s and, although Gibson's Scottish brogue attracted some ridicule, it didn’t affect my enjoyment of the movie - maybe I was comparing it to Robin Williams' Mrs Doubtfire. More recently, maybe Mike Myers' Shrek has since raised my awareness of what a Scottish accent in a movie should or shouldn't sound like but when I watched Braveheart years later, I just couldn't get past it and because of that, the film didn't feel like an Oscar winner!
If a film that won an Oscar back in the day can stink today, why should it be any different with technology and IT Project methodologies? Be relevant!
3 - Moonlight/La La Land - What Can You Learn From Last Year's Oscars Mix Up?
Do you remember this last year? Watching the debacle back you can see something is wrong from the start. Poor Warren Beaty looked very confused when he opened that envelope and rightly so. He was there to announce best picture and the card was for the winner of the previous category. He looked to co-announcer, Faye Dunaway, but she misread his pausing as an attempt to prolong the suspense, looked at the card and blurted out the winner ... La La Land.
Three lessons from this ...
i) Get It Wrong - Right!
The apologies were thorough, there was no spin. In a fortune.com post "Oscars 2017: What Leaders Can Learn from the Best-Picture Mixup" Lauren Stiller Rikleen of the Rikleen Institute for Strategic Leadership writes, "the lesson leaders of any organization can take away from this is: own your mistakes; fix them; apologize for them; investigate them, and do the best you can to move on and learn from them."
ii) Make Everything End User-Friendly.
Did you see the card that Beatty and Dunaway had? The award category was written in a tiny font at the bottom of the card and printed gold on red on the envelope. Not the easiest thing to read. It was a case of style over substance. Big font, black on white every time for me (as the end users, having been given the wrong envelope, the mistake would have been easy to spot with clearer cards)!
Same with IT Projects. Thinking about how the end user will access your completed project to deliver business results really pays off.
iii) Shout If There's a Mistake
Easy to say, but Mr Beatty could have prevented all that confusion by asking one simple question - "is this right?" You could see in his eyes he knew something was awry. When IT Projects go off course, the thing that caused the fatal problem has, more often than not, been noticed by someone but not acted upon. Create a culture where it's OK to flag up when you think that something is wrong.
4 - Get The Casting Right!
This is becoming increasingly important.
Animated movie director, Andrew Stanton once said, "Working at Pixar you learn the really honest, hard way of making a great movie, which is to surround yourself with people who are much smarter than you, much more talented than you, and incite constructive criticism; you'll get a much better movie out of it."
I love this quote and what a great way to approach casting an IT Project too!
IT budgets, more than ever, now necessitate that teams work like well oiled, focussed machines. The members of your team need to get on and work well together but you also need the skills of your talent to match those needed by your Project. More and more, these can differ from project to project and often from task to task within a project. Few businesses are able to have the luxury of idle hands waiting for their specialism to be needed, for this reason, many hire best fit all-rounders.
There is an alternative that delivers key specialist tasks as and when you need them. The Project Management as a Service market can provide skilled individual, teams and even end to end Project Management. It has never been easier to get the cast list just right.
5 - A Good Plot
Every movie that has ever won best picture has this. A great beginning, middle and end.
Your IT Project has a story arc too created in the planning stage. You meticulously plan each phase like the most gifted movie writer crafts each scene and you execute your plan as meticulously as any movie director.
Where IT Projects differ is plot twists.
In movies, plot twist are written and rehearsed. In IT Projects, we rarely have that luxury. An IT plot twist tends to blindside you from nowhere on a Thursday afternoon. It's how you deal with the plot twist that separates the winners from the nominees - scope creep, unforeseen overspends, talent calling in sick, etc, etc are all plot twists for which you can turn to the Project Management as a Service in search of a solution.
Complexity is another area where movies and IT Projects. I mean, sure, movie people probably push the boundary of their own creativity but in our world, that boundary is often pushed for us. Business needs might force us to step out of our comfort zones and sometimes creating the "plot" for these is harder but arguably more important. Again, the Project Management as a Service can solve this with tools and people on demand.
6 - No-one Remembers The Runners Up
Perhaps apart from La La Land, after the 2017 debacle, can you remember many other films that were Oscars runners-up? Or actors or actresses? It's the same with FA Cup Finals, Wimbledon, or the winter Olympics - Torvill and Dean won the 1984 ice dancing gold but can you remember who won silver? Nope.
And so it is with IT Projects. Winners get remembered. Give yourself the best chance of winning ... the right resources, the right time horizon, the right budget, space for the unexpected, a great cast and supporting cast, a compelling, relevant story and a shared vision.
Finally, and most importantly ...
7 - Be Sure To Thank Your Spouse
How often do you hear actors thank their other half? A lot! It can't be easy being married to an actor!
IT Project spouses put up with a lot too. Late night, last minute weekends, taking work home, waking in the night with a eureka moment ... being married to an IT Project professional probably ain't that easy either. I often wonder whether if we give our other halves enough credit for the sacrifices that they make to allow successful outcomes, not just individually but the companies we work for.
I recently heard of a firm that booked a restaurant table for the partners of and each member of a team who had been burning both ends of the candle to ensure that a software rollout happened on time. It was their way of saying thank you and telling the partners how much the business appreciated those sacrifices.
If you're a CIO or a Project Leader, it's worth remembering that every hour your talent spends on your project is an hour that they're away from their partners and families - reaching out occasionally to thank these supporting cast members is not just a nice thing to do, it oils the wheels for the next time you have to ask for last minute overtime.
In conclusion, while most of our hard work doesn't get recognised at a swanky awards night with a goodie bag worth thousands of dollars, it's great to work on an IT Project that feels like an Academy Award winner! No-one ever sets out to make a movie that wins more Razzies than Oscars and the same, metaphorically, is true of IT Projects.
With the right planning, preparation, supporting cast and all the other things and more that you get right every day, ... I'm thrilled to announce, the winner is ... you.
Find out more about Project Management as a Service
boxofficemojo.com - moonlight
boxofficemojo.com - titanic
fortune.com - oscars 2017 moonlight la la land
Distilled to its essence, flexible resourcing means the temporary hiring of individuals, or a whole team of professionals, who deliver clearly defined business outcomes in sync with your company or organisation's needs. It is probably the fastest growing and, for many businesses, the default means of providing both cover for and flexibility around key skills. Within this black and white broad-brush definition, there is a spectrum of shades and hues. Self-employed contractors (often on short-term contracts) may bulk up your general headcount, while specialist interim project managers might be hired to deliver specialist skills. Flexible resourcing, while it means different things to different organisations, still boils down to one simple thing - the quality of the people delivering it.
If you get the people part right, you stand a greater chance of leveraging maximum benefit from flexible resourcing. Here are seven tips to help get flexible resourcing right ...
1 - Make strategic flexible resourcing someone's responsibility - either in-house or a trusted partner who knows your culture and where your business is going. That person or partner then needs to REALLY know the objectives, strategy and existing resources, not just for the business as a whole but for your silos, business units and departments ... and how they fit your global strategy. HR do a great job with human resources – your on the books headcount – but I don’t think I’ve ever come across an FR Director!
2 - Clearly define your organisation’s current capabilities AND its needs in the future. When you get a grip on core competencies, resources and functions and you can forecast requirements moving forward and identify exactly what skills you need, when you need them, giving you the best possible return on investment. The more strategic your approach to flexible resourcing, the greater return you get, which sounds obvious but it is surprising how many businesses take an ad hoc approach to flexible resourcing! When you are able to forecast your future talent requirements, IT shifts from being a cost centre into a strategic business partner so the best in class firms measure their change in project management capability at least once a year.
3 - Encourage 360 Degree Knowledge Sharing. The best flexible resourcing results come from seamless integration of external and internal talent. If you were to take a helicopter view of such a project you wouldn't be able to tell where one began and the other ended. Can you put flexibly resourced talent through a formal induction to your company? Alternatively, ensure that your resourcing partner knows your business so that incoming talent is fully aligned with your culture and needs. When you encourage and facilitate sharing of knowledge between flexibly resourced and permanent talent the rewards are abundant. I've seen flexibly resourced talent solve long-standing issues because they have faced and solved them elsewhere before, so share as much as you can ... lessons that have been learned, mistakes that have been made, challenges that have yet to be resolved. Some firms are precious about their intellectual properties (and in some cases that's fine), most times though when knowledge sharing is a two-way street, everyone benefits.
4 - Ensure that ALL work undertaken by flexibly resourced interim talent has very, VERY clearly defined objectives. Perhaps this sounds like a stupid thing to flag up - you're buying in a flexible resource - surely you know what it is you want them to achieve, right! Amazingly, sometimes (more often than you'd think) it is the case that while a business may have identified a capability gap the specific need or desired outcome may not have been brought into laser-sharp focus. Imagine a football team identifying a gap and taking a goalkeeper on loan, and then wondering why their new signing isn't scoring the goals they needed. The flexible resources market has evolved to the extent that you can be laser focused on your actual need and get just the right person for the job. If you struggle with this, get a partner with a track record of identifying gaps and deploying the appropriate resource.
5 - Choose a flexible resourcing partner that knows its available talent pool thoroughly. There is a temptation to go with the firm with the largest ad, boasting the biggest pool but that is not usually the best option. Looking for cultural fit between your business and your flexibly resourced talent is not a luxury, it is an achievable must have. It’s no coincidence that providers who pride themselves on achieving cultural fit and finding the exact match for your strategic or specialist needs ... usually deliver this. To be fair, sometimes those flashy ad firms can do a good job bulking out more general headcount but if you have a great partner for your specialist needs you may be missing out by not running these requirements past them too! Ask how a potential flexible resourcing partner assesses candidates for inclusion on its database, how do they measure performance after each assignment and can they show demonstrable ROI? Ask lots of questions and you'll get the right candidates.
6 - Give feedback ... regularly. You do this with internal staff so why not interim talent. Think back to that football team, imagine the manager barking instructions to his players from the touchline, would he just target his 'in-house' squad or would he also shout to his on-loan players? In my experience, companies that give regular feedback to flexibly resourced talent get better results from them and, usually, the tighter the feedback loop the better with flexible resources.
7 - Ask for help. There is a reason why a whole industry has grown around flexible resourcing - it's simple supply and demand. The more strategic and specialist the role you are seeking to flexibly resource, the more difficult it is to get the right person in place. It can be hard to identify the specific strategic gap and an independent pair of eyes is often best placed to nail this and advise on the right fit. All too often flexible resourcing is a 'panic buy' - get help assessing your business need and seek advice on the most effective solution.
Flexible resources and flexible resourcing have become buzz words within IT Project Management circles, but we mustn’t forget it is actually PEOPLE who are the catalyst. Ultimately, it is the quality of your people that enables them to act and deliver as flexible resources, when you have talent with the skills to run multiple projects, diverse scenarios and virtual environments, as and when needed, then you take resource flexibility to a whole new level.
Find out more about Project Management as a Service from Stoneseed]]>
I received a nice email this week from Sarah, a regular reader of my blogs. It was a line of thanks for a previous post that had apparently "helped with some serious issues" and "improved output". Praise indeed!
I was quite excited about this. I often blog about methodologies, governance and other Project Management topics, I wondered which had been the stimulus for such positive feedback. I was surprised, as I read on, that the blog that had caused such an impact was not about waterfall versus agile, nor was it about transparency or resources or planning.
It was about harnessing the potential of every team member, even those reluctant to speak up.
The blog post in question, written last October, was entitled “In IT Project Management – He who truly knows has a responsibility to shout.” In it, I shared a story of a Project Leader friend who had been struggling with an IT Project but had managed to get it back on track thanks to a very simple trick. He listened. Not just to the loud voices who always spoke up at planning and brainstorming meetings but to those 'beta types' who often don't feel confident enough to raise their voices above the extroverts and subsequently keep their ideas to themselves.
Sarah wrote to say that when she read my post, as an extrovert herself, she was initially dismissive. As my blog said, surely it is everyone's responsibility to speak up when they have the solution and Sarah's team has always been built on a foundation of collaboration.
However, upon further consideration, she realised two things.
Firstly, that her team was made up more from characters you would describe as introverts than extroverts, the split was roughly 80/20. Secondly, she identified that most (if not very nearly all) of the ideas that were acted upon came from that louder 20% of the voices. It's not very democratic, is it?
It seems to me that this 80/20 split is probably true of many IT Project Management teams.
One team, I worked with recently included a very confident young man (who also worked as a nightclub DJ at weekends) and a larger group of, let's say, less flamboyant personnel who seemed happier and more productive working on their own. I asked the CIO to keep a record of the contribution of ideas at meetings and 'risks' taken by each team member. At the top of each league table was our friend the DJ. Furthermore, when you break down the risks and grade them 1 to 5 (where 1 is calculated and considered and 5 is audacious, bordering reckless) our extrovert was averaging 4.8 whereas quieter team members were topping out at 1 or 2.
OK, so none of this is robust scientific fact, it's anecdotal and so far, just based on the feedback of two teams.
Consider though, the talent in your own IT Project team, are they mainly introverts or extroverts?
Consider the skill set of the perfect Project Manager, would they be mostly associated with introverts or extroverts?
Truth is, that they are probably somewhere in between.
Project teams need that yin and yang. Apparently, opposite personalities acting together in a complementary manner create better teams. The most interdependent project teams are often also the most productive and interconnected ones.
Most workplaces are now built to cater more for the extrovert mindset, think of noisy open-plan offices, team building exercises abseiling off a multi-storey building and collaborative brainstorming sessions which ensnare the introvert like a rabbit in a headlight. These group sessions inevitably suit the extrovert more. It becomes a battle, where the loudest, most confident, quick thinkers triumph and the deep thinkers struggle to get a word in edgeways. Battles and triumphs have no place in collaboration. Maybe we are missing a trick.
In her book, Quiet: The Power of Introverts in a World That Can’t Stop Talking,Susan Caintalks about how extroverts are disproportionately respected. They become bosses and political leaders and books like How to Win Friends and Influence People become international bestsellers. It’s all about personality, she believes, and introverts attempting to fake it risk physical and mental illness as they live a lie or, in my experience, withdraw to the shadows taking some great ideas with them.
The reason for mentioning Cain's book is that in the preface there is an "Are You an Introvert?" checklist. Benchmarking yourself against statements about doing your best work on your own, letting calls go to voicemail, thinking before you speak, etc, you build up a score. The more ‘true’ responses you give to the 20 statements, the more introverted you are. Interestingly, having considered the statements, I find myself somewhere in the middle. I shared the list with a handful of others in IT Project Management and they too average around half true and half false.
Cain adds, "If you found yourself with a roughly equal number of true and false answers, then you may be an ambivert – yes, there really is such a word."
Maybe this is what we all are in IT Project Management then - ambiverts.
If we are 'ambiverts' then open plan office and collaborative brainstorms only inspire our best work some of the time ... if you are an introvert, Cain reckons one in every two or three is, then it can be argued that your physical working environment and practices could actually be contriving against you contributing to the best of your ability.
The holy grail then for CIOs and Project Leaders would be to create environments and surroundings that meet the needs of all mindsets.
For instance, returning to that email I received from Sarah. Her team still gets together to brainstorm but now these collaborative sessions are followed by a one-hour 'thought window' - "a chance for introspection before a final decision is taken". During this time, team members who come up with their best ideas alone - can do just that. They can literally take away the problem discussed and work out what they uniquely think - their considered opinion, not a shallow, rushed, off the top of the head response. Sarah has also instigated breakout areas away from the open plan office where team members who work best in this way can be alone to formulate their thoughts and devise solutions, giving rise to ideas that are usually better than those developed in the noise of a brainstorm. It's the best of both worlds.
When team members contribute their own ideas and solutions, they work harder than when they are following and acting out the ideas of others. Surely, this is among the main callings of leadership, harnessing the desires, opinions, perspectives and experiences of all individuals for the good of the greater outcome we are all ultimately working to achieve.
So what other great ways are there to achieve the yin and yang balance in IT Project Management contributions? How can you bring more introverted team members out of their shells? Here are just five ...
1 - Sharing the problem, subject or question ahead of the actual brainstorm has really helped me get the best from introverts who think best ‘away from the crowd’. This allows these team members to conceive a number of creative solutions and arrive prepared instead of worried. Imagine how you'd feel facing a stampede of angry buffalo - that's how one chap once described the prospect of a brainstorm.
2 - Specify how many solutions you want. Calling the meeting "20 Ideas to Reduce The Budget Overrun", for instance, sets a very clear picture. When your extroverts have motor-mouthed 10 great ideas, your introverted team members can see that there is still clear space left for them. You don’t stop brainstorming until you have the 20 ideas (but of course you can keep going after - you usually will!)
3 - Create an Idea Wall. Rather than having the anxiety of a brainstorm session land in the diary (Buffalo warning!) how about sticking a huge sheet of paper to a communal wall with a heading like "Ideas to Reduce the Budget Overrun". Email everyone to say it's there and periodically snap a picture on your smartphone and share it with the team. It's amazing how quickly the ideas stack up when there's no pressure and no-one is looking or listening. TIP - The Project leader who has had the greatest success with this idea puts the sheet on the wall of the corridor heading to the toilets - what better place to catch people with a few minutes of undisturbed thinking time just ahead!
4 - Pass the Chocolates. I love this idea, shared with me by a number of colleagues. Every brainstorm has a box of chocolates that is passed around the table but each member can only take a chocolate and pass the box to the colleague next to them when they have shared an idea or potential solution. What happens is that the chocolates kind of become a distraction from the anxiety of having to think of the ideas ... who cares about peers judging your thoughts when there's a real risk that there may only be chewy toffees left the next time the box comes to you.
5 - One Project Leader I know has developed a tactic that works. At the end of an ideas session, he asks, "Anyone else?" He has an agreement with the alpha types that they remain silent at this point and he maintains a sixty-second pause. It was stomach-churningly awkward the first few times but this silence is important. It is human nature to want to fill a silence and that's exactly what happens. One of the quieter members of the group always steps up and ideas that would otherwise be lost are given an airing.
Sometimes it can be awkward. Sometimes it can be hard to spot that a team member may be holding back their best stuff! An independent third-party Project Management partner can be a useful ally if your projects are struggling and you're coming round to the notion it could be because you're not accessing the thoughts of all your team. Having a perspective that is removed from your office politics and any fear of awkwardness can deliver transformative results. If you choose the right partner, they will interview all team members, get all perspectives (not just the noisy ones) and give you a clearer picture of where you're at.
To conclude, it seems that the loudest voices in our teams don't have exclusivity on the best ideas. Furthermore, those quieter members may indeed be less reckless and more considered risk takers. Wouldn't all our projects benefit from hearing these voices more?
Find out more about Project Management as a Service from Stoneseed]]>
More and more of our clients are saying this is their biggest pain point. So how can you avoid having to fit a round peg in a square hole?
The time between hiring and getting talent up to speed can make all the difference. In IT Project Management, it's not just where the loos and the coffee machine are, for a hire to be considered effective you need them to hit the ground as close to running as possible. Therefore, your onboarding process, how you embed them into your organisation, has to be given some serious attention.
Many organisations do this really well. One client has a great approach to onboarding detailing processes and preferred methodologies, how projects get green-lighted and who initiates them, how resources are allocated, risks are managed, budgets are planned, costs are controlled and tasks are scheduled. They have fabulous flexibility too, after all, onboarding a Project Manager with the ink still drying on their Prince2 certificate is a different prospect to onboarding a new colleague with twenty years’ experience under their belt.
This client's approach is an "A Game" textbook example of how to do it but even they list onboarding as a frequent issue, especially when bringing in contractors who walk in “cold”.
Here's 5 Onboarding Tips To ... er ... get on board with. #SorryNotSorry
1 - Consider PMaaS
With the right Project Management as a Service partner you will get a better fit because, if they're worth working with, they will have got to know you, your processes, the methodologies you use and MOST importantly ... your culture. Cultural alignment is crucial. Matching character, skills and personality of the 'resource' with your organisation could be the secret to more successful onboarding.
You can't guarantee project outcomes if your cultural compass doesn't point in the same direction as your talent's. For instance, if they are hard-wired to brush issues under the carpet and you have a culture of transparency or if you work late nights and long weekends and they want a nine to five, there will come a point where the friction between these opposites causes you some pain.
That's not to say that talent can't adapt to fit your culture - it's all about managing expectations from the outset.
Your Project Management as a Service partner can help you achieve this, for instance, we brief talent during our induction process and focus on understanding the customer's needs and culture during the project workshopping process at the start of any relationship with a new client.
2 - Make Culture Part of The Onboarding Process
Methodologies and processes, risk management, budgeting, cost control .. all of these matter to effective onboarding but they are all administrative functions. A lot of IT Project success comes from the heart! When IT Project talent is really bought into your organisational values they operate in a more visceral, intuitive way and successful outcomes appear more effortless.
One of the biggest challenges is that many companies and PMOs haven't identified what their culture is, so they don't know how to portray it to others.
Get to know your culture so that you can effectively communicate it to new talent. The earlier you start the better, working with a recruitment partner to access talent that is culturally aligned with your values makes for a smoother onboarding experience.
3 - "Stay Beginners"
Steve Jobs used to have a talent for seeing products through the eyes of a new customer, he called it “staying beginners”. Constantly looking at products as if for the first time gave him an insight he could leverage. It’s how Apple decided to make iPods that were ready charged out of the box, an industry standard for gadgets now but a concept that didn’t exist with tech previously.
When onboarding IT Project Management talent "staying beginners" could mean avoiding project specific jargon. You remember starting somewhere new ... things move so fast ... the last thing you need is to have to translate communications into a common language. Make it a habit to explain acronyms that are second nature to you. Project-specific language can be really confusing for a new starter and every time that they have to stop and ask what something means causes a delay and makes them feel like an outsider.
Seeing the onboarding process through the eyes of the new person dramatically speeds up integration.
4 - Take A Broader View of What You Can Share with New Talent
After canvassing the opinion of talent about onboarding pain points, the most common complaint is that they don’t have access to all of the things they need to make effective project decisions.
Most companies have taken a view on new starters, especially freelance contractors, and what they will give them access to and what they won't ... CMS, access to team members' calendars, operational information, tools like access to conferencing services... and so on.
The most common response from organisations about why they restrict contractors access to certain project crucial tools is trust! It's not that they distrust the talent per se - they're trusting them with delivery of the IT Project - it's just that a lot of information is sensitive. Invoice management and financial information, resources that are shared across the project portfolio, passwords, sensitive contract details are all things that freelancers have told me they have restricted access to but which can restrict your talent’s effectiveness.
The problem is that even great Project Managers cannot breathe in an information vacuum and many projects suffocate as a result. To avoid this try to take a broader view of what you allow them access to - to be able to do this you have to trust your talent. Perhaps trying the PMaaS route suggested earlier for "non-staff" freelance talent and using a recruitment partner to access talent in a culturally aligned manner will give you a cushion of trust between you and those you rely on to deliver your project.
5 - Handover Is Key - Why Why's the Wisest Word
If the departing PM is still with you, make sure that he or she spends an adequate amount of time handing over the reins of the project.
Now ... sure ... share what has been achieved already, where is the project on its timeline. What issues and risks remain unresolved ... How are the numbers stacking up financially - is the project on budget? This all matters ...
I think that when handing over an IT Project, more important than the "hows", "wheres" and "whats" are the "WHYs". Why has the budget been set at that level, why is delivery needed on the date agreed, why were certain decisions made?
Understanding the "why" behind the IT Projects helps really embed new talent. Project Managers are, by nature, instinctive - when they understand the DNA of the project they will find their way and make intelligent outcome-based decisions much faster than if they were given just its nuts and bolts history.
Onboarding new staff is a vital part of the success of a PMO or IT Project team of any form, yet it is a key ingredient of successful projects that many Project Managers and CIOs fail to notice or copy. Make sure that new starters are not only welcomed but also supported and encouraged during their initial few months with you. We were all new starters once, remember what it felt like and as Steve Jobs said - "stay beginners".
Find out more about Project Management as a Service from Stoneseed]]>
"Could buying in Project Management As A Service be an alternative solution?"
"Of course," I remember saying, "but let's first drill down and work out what's going on here!"
I looked at his project portfolio and the staff assigned to each task. Over and over a picture of mismatched talent began to emerge. They were working to a system that practically assigned project responsibility to whoever was free next, regardless of suitability and compatibility.
It was an object lesson in why giving the right manager the right project to manage is key to successful outcomes.
Of course, with an internal PMO you are rather fishing in the same small pond, but it is amazing how many project management contracts are awarded to contractors just because an organisation has used them before. IT projects differ in scale and complexity and your "go to guy" delivering last time is no guarantee of success on future projects.
Beyond this though, I have said for years that cultural alignment matters hugely.
If your organisation has core values of transparency and accountability you don't want to be working with a Project Management partner that buries bad news or hides mistakes - their smoke and mirrors approach just won't fit with your open approach, eventually key milestones and targets will be missed, projects will fail.
For example, my company Stoneseed has a people based ethos - we seek first to understand your business case and specific requirements and then we recruit people to match those needs and individual projects. The goal is two cultures dovetailing beautifully creating results beyond expectation.
Increasingly, cultural alignment of PM talent and client organisations is going to become as important as getting the right manager to do the right job.
BUT ... You don't even have to like your contractor!!
I'm aware of at least one relationship between a fairly brusque CIO and an equally brash contractor that seems to thrive in spite of itself. I assumed once that because of the high success rate of projects managed by the contractor he must be held in high esteem by the CIO but was amazed to find that the two actually hated each other, I mean they literally couldn't stand one another. They did, however, have mutual respect - in a business sense at least - and the fact that they were both as rude as each other seemed to be the glue that held the relationship together. There was total (often vociferous) transparency - these guys told it as it was ... each giving as good as he got from the other. It's an extreme illustration but you cannot argue that the two weren't culturally aligned and they got results.
Another Project Manager gets work by turning it away. Organisations approach and if he does not believe that the aims are achievable or that outcomes would be congruent with his client's business case he declines the offer and gives honest reasons why. Sometimes the client gives the work to someone else and his forecast becomes reality but more often than not the organisation enters into a dialogue where an alternative solution is created. His core values are aligned with organisations that value honesty and calm measured thought over reckless risk taking on an outside chance. Organisations come back time and again.
You see, the same freelance Project Manager can do a remarkable job for one organisation and then, based on glowing references, secure an identical project with another company that fails to deliver spectacularly. Same scale, same scope, same skills, same time frame delivering totally different results. In most cases it's down to a cultural divide between the contractor and the organisation.
Whether you're looking to hire staff to fit within your internal PMO, recruit external PM contractors or seeking to buy in Project Management As A Service (either to sit beside your existing structure or replace it), knowing your organisation's culture and aligning it with that of your prospective Project Manager will increase your chances of success.
Any potential partner worth their salt will have already done their homework on you - and they don't deserve to get your business physically if they don't get your business emotionally.
Find out more about Project Management as a Service from Stoneseed]]>
This is the key take home from a survey from AXELOS ahead their Summer reboot of PRINCE2.
"Organisations will demand greater business awareness from project managers in the next few years. As a result, project managers need to invest in their own professional development so that they gain the skills required for a successful future," says the company on its website.
So what does this mean and how big is the gap between where you are now and where AXELOS thinks you need to be?
It is interesting that nine out of ten Project Managers surveyed believed they needed greater strategic vision that was aligned with the goals of their business. I don't know whether this is heartening or worrying.
Certainly IT Project Management MUST be aligned with business strategy, it must have a business case - otherwise what's the point ... so on one hand ... great, right?!
On the other hand, it's 2017.
Clearing out some old paperwork the other week I found notes from a project pitch from 2008 and circled, in orange highlighter pen, were the words "BUSINESS CASE". Underneath this were irrefutable links between the proposed project and business strategy at the time. It wasn't a new idea, I'd been looking for strategic justification for IT Projects for some time, even by then, so it's perhaps surprising that nearly a decade later 90% of PMs still feel a need for a clearer strategic vision. Perhaps now is a good time for all of us to check our Projects for strategic alignment.
By addressing this one thing I believe we will exponentially improve output.
Sometimes it can be hard when you work in IT Projects day to day you can easily lose your strategic compass. More than half (58%) of organisations report poor alignment of projects with their organisation's strategy, in my experience it's one of the biggest killers of project momentum.
An independent project management office assessment can often be a brilliant kick-start. Usually, a pair of fresh eyes taking a look at your project portfolio can spot gaps and advise where alignment with business strategy could be stronger.
If, after business case analysis of your project portfolio, you find gaps there are plenty of solutions in the Project Management as a Service industry - if you had an independent firm carry out your analysis they should be able to advise. Just make sure that have really taken time to understand your business vision!
So, Project Managers and their teams have a key role to play in this BUT 90% of Project Managers needing a clearer strategic vision does not make them bad PMs. It would be utterly wrong to place the blame for this disparity between projects and business strategy solely at the feet of the project teams. Much of the responsibility for this should be shouldered higher up your business hierarchy.
I once heard a television ad writer saying that if an advertisement doesn't work it isn't the audience's fault - it's his. So it is with any communication when a message doesn't penetrate it is the giver not the receiver of the message who should consider their approach.
Senior business leaders must improve communication of business strategy. In many cases, they literally need to learn how to communicate their strategic vision with the clarity needed to leverage the full potential business benefits from IT. Businesses that I've worked with that have embraced and acted upon this truth are rampantly driving transformation in areas that had stalled.
The top-down approach works! Project Leaders have a vital role to play here too though. By having the guts to ask searching questions, that really drill down to what your firm’s organisational vision really is, you increase your value as a Project Manager within your business. That is going to become more crucial.
The AXELOS report, "The Future Project Management Professional", based on the survey I mentioned earlier reveals that over three quarters (76%) believe "project management" will become a basic business skill which everyone uses. The best of the best will the practitioners who have this extra strategic level to their approach.
There is definitely something in the air. PRINCE2's Summer reboot will place greater emphasis on projects targeting specific needs and business objectives, I know that at least one major UK company is currently meditating on this issue and friends working in IT within the NHS tell me there is a much greater emphasis on business case development and benefits realisation than at any time in their career. So what better time to join in!?
It's one of my passions.
For me, there is huge satisfaction to be gained from re-coupling IT Projects and organisational strategy but (perhaps) more importantly you will revitalise your IT project team and yield greater business results from IT.Find out more about Project Management as a Service from Stoneseed
When I asked associates, acquaintances and clients (who had all recently recruited for IT roles) how many had used personality type or psychometric testing, 7 out of 10 said that they had.
I recall the response from a survey by the Society for Human Resource Management to this question was around one in five. That was about six years ago and although my little poll was far from scientific - it does suggest progress.
The reason for my renewed interest in this is that I have been interviewing recently. As part of the interview process, the candidates were given a project scenario, a technology project across several locations and they were asked to develop the plan including a presentation and a project initiation document (PID).
One candidate fed back that they found this a really uncomfortable task.
When we asked why the candidate said it was because they had to make assumptions as not all the information was available.
Personally, I find this one of the most exciting parts of the art of IT Project Management and it is an art! If every shadowy corner of a Rembrandt masterpiece were painted so you could see exactly what was there, the picture would lose much of its beauty. So it is in IT Project Management. The shadowy corners of IT Projects are where the heart beats faster.
You'll know from your own experience that some Project Managers are great at this. They can put together the jigsaw that is their project with an infinite number of pieces missing. If you ask any of them, they'll probably tell you that the secret to their success is that know how the Project will eventually look and feel - to stretch the jigsaw metaphor they have the picture on the front of the box to refer to.
If this IS a necessary skill then whether you're recruiting new talent, enlisting in-house talent or buying in talent through the IT Project Management as a Service market you need to be sure that your talent choices reflect your business culture and needs.
To return to the example above, in real life, you have to make assumptions and guesstimates, you have to use your skill, judgement and instinct or projects can just grind to a halt! So how do you make sure that you recruit people who can do this?
One CIO once told me that he fills his team with "B to Y people". He searches out Project Leaders who can take his projects from A to Z because they have the experience and instinct to know where the letters B to Y are meant to go in between.
Some Project Managers are great at this but others are not. Many are just not prepared to make assumptions or even present a possible solution with a stated assumption. They will only proceed with all the facts. This is why a lot of IT Projects stall.
A Project that I was asked to consult upon last year had hit exactly this problem. The Project Leader had correctly called the route ahead but was waiting for hard data to back up his instincts. When we looked into the hiring process there had been no personality type or psychometric testing. The Project Manager had interviewed well and had a track record of successful project delivery but none of these projects had an element of having to instinctively "join the dots". He was a great Project Manager but wasn't right for this one!
In this case, personality type or psychometric testing could have helped. However, before you invest your whole recruitment budget in this field there are things you should consider.
Psychometric testing can tell you which candidates are not right for the job but they won't necessarily tell you who is the best for it. The CIO I mentioned earlier uses testing to fill his team with "B to Y" people but only as part of a broader recruitment strategy. He summed it up neatly by saying that the testing tells him which candidates will identify the letters between A to Z but it's the other elements ... like peer profiling, the interview, work sampling exercises ... that reveal who will get them in the right order!
Another consideration is your business needs - do you know them?
Personality testing without first understanding your business needs is as ineffective as recruiting based on astrology. I mean, Aries are meant to be strong-willed and exacting in their work but would you hire your next PM just because they were born on April 5th? Of course, you wouldn't.
Psychometric testing will usually not help if you don’t have clear and specific measures of what good practice and performance looks like or how performance is aligned with business case. Too often, hiring businesses don't have quantitative measures in this area so psychometric tests cannot predict candidate performance effectively. It can be hard to correlate business strategy and the performances needed by your employees or contributors to deliver it so it's often worth taking on a recruitment partner or services provider who will really get to know you and your business needs before recommending talent solutions.
When the recruiter or service provider knows what they are trying to measure and why your chance of a good match can increase exponentially.
Finally, having psychometric testing compiled or carried out by Subject Matter Experts can increase the potency of the data returned. In my experience, 'True/False/Cannot Say' verbal reasoning questions, for instance, give you a better idea of the suitability of Project talent if they are written or selected by someone with Project Management experience.
In conclusion, psychometric assessment may be the future of effective recruitment but in IT and especially IT Project Management it should be deployed as part of your arsenal and if you take into account all of the above you should end up working with exactly the right people to deliver your business strategy through IT.Find out more about Project Management as a Service from Stoneseed]]>
Harvard Business School professor, Theodore Levitt, once put this beautifully, “People don’t want to buy a quarter-inch drill. They want a quarter-inch hole!”
Think about that for a second.
Recently, a Project team, a team I work with had identified that replacing desktop PCs with iPads would have a number of benefits. The business is a trade centre and carries a lot of stock that can be accessed by tradespeople by phone, online or (more often than not) in-store. You walk in, ask if they have a part in stock and after checking on their PC the clerk prints off or scribbles down the warehouse location on a Post It note.
Replacing the PCs with tablets would mean the person serving you could be half way to the warehouse while the stock check is carried out. The benefits included freeing up staff, who couldn't stray too far from their PC station but with an iPad, a member of staff arranging a display outside could greet a customer in the car park and have their order ready almost before the alarm on their van had finished.
It would not only speed up customer service but also improve stock control and ordering, reduce printing and paper costs (not to mention the maintenance and waste that printing causes), it would make the business look more current - iPads suggest "cutting edge" more than the sound of a dot matrix whirring away.
Two paragraphs of benefits and I've hardly scratched the surface. So how come the Project got rejected? You've probably guessed ...
"We want to buy 20 iPads and some new software."
The tech guys were excited about what they could do with 20 iPads and some new software ... they were going to revolutionise the business. To the board, 20 iPads and some new software sounded like capital expenditure and they'd just made it clear that the business should be saving money not spending it. They sent the IT guys away with a flea in their ear and their tail between their legs.
After licking their wounds, a week later they met the board again but this time explained that they wanted to revolutionise the business. They sold the benefits and the board bought it, excitedly asking ... "how?".
They signed off the purchase of 20 iPads and some new software.
Benefits sell and details don’t.
The main reason why details or the features of an IT Project don’t sell is that sponsors, board members and end users simply don’t care about them. Think about when you buy a car. OK, you might use a list of features to differentiate between two similar vehicles, but those features in and of themselves won't be the reason why you drive one off the forecourt and not the other. It will be based on feelings, perceptions and, yes, what benefits the car will deliver.
Sponsors want IT Projects to deliver a specific task or business result. The project is the means to an end.
Explore the notion further.
Do you want a new lightbulb or do you want to see in the dark?
Do you want the latest Jamie Oliver cookbook or do you want to dazzle your friends at your next dinner party?
Do you want a garden table and chairs or do you want to be able to eat al fresco?
Do you want an IT Project or do you want the solution to business challenges, monetisable deliverables and healthier profit margins?
Next time you write a pitch for IT Project funding, concentrate your attention on the hole, not on the drill, remember that's what you sponsor is looking for!Find out more about Project Management as a Service from Stoneseed]]>
Key to the successful delivery of the IT for the London Olympics has been the establishment of a robust program and project management at the heart of a multisourcing framework. To read more on this story follow this link.]]>