I’ve just watched a news article about the brokering of trade deals, what they are, why countries need them, the benefits of them and how difficult life can be without them. It got me thinking.
What they were describing, on a geopolitical level, shared so many characteristics with a struggling IT Project that I’d been asked to cast a casual eye over.
The Project team is a mixed group. Twenty-somethings with their freshly minted Project Management qualifications working side by side with more, er, shall we say more seasoned, more mature practitioners (who have years of experience). The biggest issue is that the individuals in the project team don’t have a lot in common, largely because of their age gaps, backgrounds and experiences!
In fact, the individual members of the team are like separate countries on a continent. Each has their own agenda; each has their own “way”; each has their own proud history. You can see why the news report on trade deals resonated.
Added to the mix, the project team is a prolific user of Project Management as a Service resources. Whenever they have a resource issue, I get a call and hook them up with brilliant talent from the PMaaS universe who can parachute in and ‘save the day’. This adds an extra variable that can skew the team older or younger, etc, at any given time.
Trade Deals Within IT Project Teams
Each of us working on an IT Project has a CV, it’s how we got the gig! Each entry on those CVs is a unique data point that can be mined for the benefit of everyone on your team, not just your current team but every team you will ever work on.
Think of the exponential knowledge bank that is literally sitting in the room with you when you work on an IT project. How many people on your team? Multiply that by how many projects they have worked on. Then, multiply that by the number of people that would have been on each of these projects, and this new number by all of the projects on their CVs. Imagine that each point is like an entry in an IT Project Management encyclopaedia. It’s like that legend about the grains of rice and the chessboard where the guy asks the emperor for a grain of rice on the first square, doubled on each square thereafter.
Why wouldn’t you want to enter into a “quid pro quo” trade deal with everyone you meet with access to this kind of knowledge bank?!
Let’s consider the project that I’d asked to take a casual look at. Take two of the team members, I’ve changed some of the details to respect privacy but imagine these two:
Brandon is 29. He has a few years of experience under his belt. IT, project management and this particular team are all he’s ever known. A resume of his last 15 years would read: computer club leader at secondary school; tech degree at university; gained project management qualifications; landed project management job with current employer.
Jennifer is 49. She has many years of experience under her belt! She has just returned full time to the industry after raising her two boys. The company she started her project management career with is long gone, as is the one she was working at when she left to start her family! She has seen many changes! She maintained a part-time presence through what she calls her ‘priority parenting’ years, benefitting from the flexibility of Project Management as a Service opportunities to keep her hand in.
You can see how differently these two will see their jobs, roles and careers. Even down to getting the whole team together for a social night out is tricky – Jennifer loves a sit-down meal and nice wine with a taxi home at 9, Brandon prefers the pub, followed by a club and an Uber home for a few hours of sleep before work later the same morning!!
Getting such diverse team members to interact and bring their complementary skills to their projects is the key to turning around this struggling team. I think that “trade deals” is the way to do this.
Brandon is great at cutting edge tech, trying new methods and project software, Jennifer prefers to use her tried and tested software (she is, by the way, a spreadsheet genius!)
Brandon can be a little abrasive, he ‘rubs’ people up the wrong way – often without realising. Jennifer has EQ in abundance and years of experience have taught her that diplomacy in negotiation is usually more effective than stamping your feet.
The tendency so far has been to split the team into likeminded sub-teams for completion of project tasks, so the young, abrasive, go-getters head in one direction and the more mature, experienced go in the other. I’ve suggested that they work together more.
This is where the “trade deal” comes into it.
Put the Brandons and the Jennifers on the same team and, alongside the obvious completion of tasks, there should be a direct instruction that they learn from each other. A “trade deal” – mutual mentorship!
In two future blogs, I’d like to drill down on the Brandon and Jennifer dynamic. Airbnb’s Chip Conley’s thought leadership on the concept of ‘modern elders’ has much to teach more experienced project team members and leaders blessed with this resource on their team. I also think that there is a lot that can be done to allow more junior members of the team be heard. So watch out for those blogs!
“Mutual mentorship is the future.”
Perhaps the most famous evangelist of “Mutual mentorship” across generations is Airbnb’s, Chip Conley. His Tedtalk and his lecture for ‘Entrepreneurial Thought Leaders’ (Stanford’s Speaker Series) are inspirational insights into this way of thinking. Conley had been hired to help mentor Airbnb cofounder Brian Chesky, but quickly discovered that he had a lot to learn himself. He is the first to admit that he wasn’t the most tech-savvy new hire when he was headhunted by Airbnb at 52 years old, he didn’t even know what Uber was! However, he set out to see if his “wise eyes” could learn something from his new colleagues’ “fresh eyes.”
What he discovered was that sharing knowledge, combining his many years of experience in the hotel and hospitality industry, and his leadership skills, with his new colleagues’ digital expertise and fluency, would benefit the company as a whole.
“Opening a pipeline of organizational wisdom is the trade agreement of our times,” he once said. “That’s the new sharing economy—sharing wisdom across generations.”
“Mutual mentorship is the future.”
The Biggest Missed Mutual Mentorship Opportunity
In IT Project Management there is another mutual mentorship opportunity that is often overlooked. We sort of touched on it earlier – it’s PMaaS.
When you use Project Management as a Service resources you are adding fresh eyes, different perspectives and a whole back catalogue of unique experiences to your team. Why wouldn’t you see this as a great learning opportunity? Sadly, few do!
What happens in most organisations is this: the PMaaS talent arrives; they do the job they were hired for; they leave.
All that extra experience departs untapped with the talent. What an opportunity missed!
What happens in GREAT organisations is this: the PMaaS talent arrives; they do the job they were hired for; AND all the while in-house talent becomes a knowledge sponge for new ideas, different approaches, fresh ways of thinking.
It’s interesting to note that the PMaaS talent themselves are more than likely always doing this. It’s part of their DNA to be inquisitive about alternative methods because adding them to their skillset increases their value. When you hire PMaaS resources it is worth remembering that you are not just hiring in a pair of hands to help deliver a project, you are buying the accumulated knowledge of everywhere they have EVER worked.
Again, why would you not want to learn from this!
In conclusion, we have never had such great access to knowledge about IT Project Management, the internet is teeming with it! But Project Management remains an inherently human pursuit, it’s the fingerprints on a project that bring it to life way more than the code! The most fulfilling way to learn is to share, to interact and, yes, to steal great ideas from each other!
So, look around your office, think about the members of your project team, observe the temporary guy contracted in from your Project Management as a Service partner. What great insight are you going to pinch from them today?
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
A Project Management contractor friend of mine said this as he told me about a monthly meeting that had just appeared again in his diary with the subject “Team Meeting – All Staff To Attend”.
“You’re not staff,” I said, “You’re a contractor.”
He shrugged and gave a resigned sigh. Yeah, but what are you gonna do?”
The meeting was a monthly update given by the CEO about the health of the company, sales performance, new benefits and incentives for staff and, at the end, a bottle of wine was given to the employee of the month. Again, as a contractor, none of this applies to my friend leaving him feeling a little left out and not part of the team. It’s actually quite demotivating him being there!
Now, I’m not even going to get into the IR35 implications of treating a contractor like a member of staff, that’s a whole other blog right there!
No, this one is about meetings. How to run them and who should be there. In an industry where many IT Projects are still failing, or at least not yielding maximum returns, I can’t help wondering if we spend too much time sitting around the boardroom table when we could and should be working in and on our projects.
Just this last week, I made calls to three industry colleagues with whom I could not be connected because they were in meetings. When I finally did talk with them I asked how their meetings had been and what end they had served – of the three only one told me their meeting was strategically aligned with their business or project goals, none of the three said that the meeting had any value, one of them even said, “Face shown, box ticked.” Is that how little we value the precious resource that is an IT Project Manager? No wonder so many projects fail?
Elon Musk knows how to run a meeting. Tesla famously reframes the accepted norm and I love an email that he sent out about meetings. This was shared by Justin Bariso on Inc.com and Business Insider and should be posted on every meeting room wall on the planet!
These are Elon Musk's three rules for better meetings:
Brilliant isn’t it?! Let’s break it down.
1 – Smaller Meetings
Regular readers will know I love a football analogy! So, imagine Old Trafford at 3 pm on a Saturday afternoon. There’s probably just over 75,000 people in that ground when United’s winning goal is slotted into the net a minute from time. BUT how many of them took a touch? 74,879 are in the terrace cheering the red devils on, they didn’t get a kick. Eleven of the players on the pitch are with the away team, the ref, his assistants, the backroom staff, the young lad selling the programme and the man who heats up the pies, they’re all there “at the meeting” but when it comes down to scoring that winning goal … it’s Maguire to Pogba to Rashford, Rashford rounds the keeper and smashes the ball into the back of the net.
It can be the same with meetings at work. It’s nice to have a pie and it’s nice to have someone cheering you on, but at the end of the day (football cliché there), you only REALLY need a handful of people to score that winning goal. Anyone whose attendance doesn’t make a difference is just a face in the crowd.
And talking of which …
2 - If YOU are not adding value to the meeting, get up and leave.
If you turned up at your friend’s wedding and realised that you’d gone to the wrong church, you wouldn’t stay to hear the vows and go to their reception instead.
This happened to my friend a few weeks back by the way. He’d arrived late and so had to sit at the back and was just wondering why he didn’t recognise anyone when the organist struck up “Here Comes The Bride”. A total stranger walked in dressed in a bridal gown and the penny dropped. He waited for the bride to pass and then snook out the door through which she’d just entered.
Have you ever been in a work meeting like this? When you realise you’re in the wrong meeting (even if your name is on the attendees list), why don’t you just get up and leave? There is no creaking church door, no elderly aunts to tut as you squeeze past treading on her toes, no groom wondering who that mysterious man is who left red face as soon as his fiancée arrived!
You don’t, though, do you? You sit there thinking of all the work you must get done when you finally escape this stuffy room!
It would be really awkward to get up and leave – that’s why no-one ever does. So it is important that we manage this for our meeting attendees and before sending the invites, take one last look and ask if they will add value. Be brutal for the greater good.
3 - No frequent or recurring meetings.
Recently, a CIO friend of mine decided to cancel a regular Monday morning “State of The Portfolio” meeting. The catch up had been a nice chance to see colleagues face to face and discuss any issues or challenges. Nice idea.
The thing was though that increasingly they were just reading from project management software entries or their project’s Gantt chart which everyone has access to anyway. Indeed, most of the things they’d discuss had been flagged and were in the process of being addressed.
They decided that this was a pointless duplication and unless there was a major issue that needed talking over, they’d cancel the recurring meeting (whilst leaving the diary space available just in case!) Six months later, there hasn’t been a single issue that needed this weekly meeting to be held! All that time wasted!
A friend’s mother went to the doctors with a condition that the GP thought might need long term treatment, perhaps medication for life and monthly appointments to assess whether her condition had changed. Three months in and the doctor was amazed at how well she was responding, and the following month declared her ‘cured’. She didn’t have to be assessed every month any longer, so she asked the receptionist to cancel the rest of the blocked-out appointments. The computer system decided it didn’t want to do this and months later, she got a call from the doctor’s receptionist reminding her how much missed appointments cost the NHS! She is a strong-minded northern woman of a certain generation who, when wronged, is unlikely to take prisoners. That doctor’s receptionist learned the folly of recurring appointments right then, maybe we all should too!
In conclusion, I return to my opening point. Project Management depends on increasingly stretched resources. If you have a Project Manager on your books or through a Project Management as a Service partner, you should treat this resource and their time as precious.
Every second lost is a second that could have a positive impact on your project and your strategic business goals. Don’t waste that second asking them to watch as you give Joyce in HR another bottle of wine.
Find out more about Project Management as a Service from Stoneseed
Let me start by saying - it should be a challenge.
Ground-breaking IT Projects that disrupt markets, drive innovation and create new revenues should push you to the outer edges of your limits and capabilities. Otherwise, what's the point? Challenges are like bacteria, there are good and bad challenges. What you need is the Project Management equivalent of Yakult! It exists, read on!
Challenge is good when it fosters success but, increasingly, clients are telling me that they are struggling to find the right resources or the time that their project demands? That's not a good challenge.
Let me share some of the other 'bad challenges' I hear, and you tell me if they ring a bell with you.
Do you, for instance, struggle to keep costs contained and predictable? Do you find your Project Management capabilities lacking (projects are more and more complex but have your in-house capabilities developed at the same rate)? Do you encounter the same issues on successive projects? Can you identify the same failure points time and again? Do you lack business intelligence reporting? Is your Programme Management Office ineffective? Is it hard to find resources that can flex up and down as your project demands it? Do you find yourself constrained by a conventional contract resource model?
If one, a few or all of these chimed with you, there is a fix. PMaaS.
You can improve your IT project delivery with Project Management as a Service.
What is PMaaS?
PMaaS kind of does what it says on the tin. You can buy in project management services ... on demand. It gives your project team access to talent that specialises in cutting edge project management - skilled and talented IT Project professionals who can jump in and hit the ground running.
Stoneseed’s Project Management as a Service (PMaaS) offers you access to Project Management staff, resource and tools at a flexible and predictable cost via a fully structured Managed Service, underpinned by KPIs and SLAs.
With some reasonable planning, PMaaS provides access to a wide portfolio of project skills, made available against your demand schedule, so this could be a single Project Manager for a few days or a large team of fully utilised project professionals. We provide a complete range of Project Management and Business Analysis services, including full Programme Management Office (PMO) providing assessments, governance, tools and people to improve your delivery capability and performance.
Set to a tailored budget, in accordance with agreed service levels, your business can secure the consistently high-quality project delivery you need, often with no net increase in the overall portfolio costs. So, whether that’s skilled resource provision or a fully Managed Service, Stoneseed can help you maximise your project success and improve your IT project delivery.
So that's the sales pitch. But what are the actual benefits?
I asked colleagues and clients to each share a benefit of PMaaS and quickly started to feel like John Cleese as Reg in Monty Python's Life of Brian! You remember the scene? Reg asks what the Romans have done to help and everyone pitches in with suggestions until, in the end, Reg says, "All right, but apart from the sanitation, the medicine, education, wine, public order, irrigation, roads, a freshwater system, and public health, what have the Romans ever done for us?" Then Xerxes pipes up, "Brought peace."
So, when I asked, "What has PMaaS ever done for us?" This is what you told me:
Flexible on-demand resources;
High-quality project delivery;
Predictable cost model;
Business Analyst And Project Management expertise;
Honest Perspective (PMaaS tends to reveal truths that are hidden or brushed under the carpet. Having a fresh pair of eyes look over your operation often shines a light on missed opportunities);
Resource onboarding, retention and exiting;
No net increase in portfolio costs (With PMaaS, you pay for what you need);
Governance, metrics and reporting...
I bet, like The Life of Brian's Xerxes, you can add another! I’d love to hear from you. Actually, Xerxes suggestion of "brought peace" works both for the Romans and Project Management as a Service. Peace of mind is definitely one of the hidden benefits of engaging with a PMaaS partner.
To conclude and to return to my opening point. Great IT Projects SHOULD be a challenge, it's how you meet the challenge that counts, and this can be the fine line between failure and success. In any walk of life, deploying the best available resources yields the best return. In IT Project Management, PMaaS gives YOU access to the best resources - on demand.
Find out more about Project Management as a Service from Stoneseed
You tube – Monty Python
I think "amazing" is the most over used word in the English language these days, usually with the middle 'a' elongated, "amaaaaaaaaaaaazing". I blame Love Island. Anyway, I digress, the chap I was talking to seemed genuinely taken by the ground-breaking, "amazing" new concept that I'd shared, he picked my brains for a good few minutes and even grabbed his iPhone to create a note.
What was the thing I'd mentioned? SMART Targets.
I know! Hardly ground-breaking or new, you might say SMART targets are even a project management basic. He was right on one thing though, they are "amaaaaaaaaaaaazing" but if this one project manager is anything to by, it seems some projects have lost the art of SMART, or worse still, never learned it in the first place. "Amaaaaaaaaaaaazing"
This got me thinking. I've noticed other concepts that, to me, are IT Project basics that are increasingly being forgotten, overlooked or are just not part of the DNA of Project Managers and their teams. In this short series, we'll explore some of them. If your project capability is stretched, if you are having to cut corners on project basics (like SMART targets) then the Project Management as a Service sector has an abundance of resources to help, from better project software to end to end Project Management Office.
Today then ...
Every day we subconsciously set ourselves thousands of targets, whether it be to make an early morning coffee or to remember to put the bins out on bin night, however some goals require a deeper level of goal setting, this is where SMART targets come in handy.
The notion of SMART targets may appear basic but increasingly and perhaps paradoxically, as IT projects have become more complex, teams are forgetting to do some of these basics. It is a common symptom that I see in projects that are failing - teams are to busy working in their projects to work on them.
To quickly refresh our minds, let’s look at exactly what a SMART target should consist off, what each letter stands for ...
What is it that you’re trying to achieve, try to be as specific as possible when deciding on your goal. For example, rather than saying 'I want to complete the coming sprint' state exactly what you want to complete, this way you are more likely to focus on those specifics. Habit 2 of Steven Covey's 'Seven Habits of Highly Effective People' is "Begin With the End in Mind"
How are you going to measure how close you are to completing your target? How will success be measured? I remember this quote from way back in my school days, it is from Galileo Galilei, it goes "Measure what is measurable, and make measurable what is not so." Love that! There are many different ways of measuring IT Project success, for example you may decide that you want to achieve a certain number of deliverables, or a certain level of stakeholder satisfaction. You may want to meet a budget, deliver a specific return on investment (ROI) or level of quality.
Attainable / Achievable
Making sure a target is achievable is key. Setting unrealistic targets will likely lead to unnecessary stress as well as failure. All too often, physical and financial resources are the measures of attainability but it also pays to consider the experience of your team, i.e., how it will feel for them. If delivering this is going to drive them to drink or to look for work with other projects, then your goal is not achievable - at this moment! Consider PMaaS resources to bolster your capability and ease pressure!
When anyone sets a goal it should be relevant to their individual needs. This is why most diets fail! If the need for chocolate cake, a glass of wine and fish and chips on a Friday is greated than the need to lose weight, i.e. weight loss is not a relevant goal, guess what will happen. The same goes for goals set in IT Project Management. All goals should be relevant to the overall aim of the software being developed, the business change that is needed or the strategic goals of the organisation.
Timely / Time bound
Finally, you need to set yourself a completion deadline. It is important that the deadline is realistic but pushes the team to work hard. A project leader shouldn’t set their team a week to complete a task that should be done across three weeks, which sounds obvious but commercial pressure as they are, too many friends are burning out trying to deliver ROI unrealistically quickly. If you are feeling commercial pressure to say 'yes' beyond your current capability you should explore PMaaS.
Who are the fans of SMART targets? What benefits do they bring?
Surveys carried out by the Institute of Personal Management found that 62% of UK companies use SMART targets as a way of motivating talent and improve performance levels. Byron Pulsifer, an author specialising in self improvement books, champions them. He says that those who use SMART targets are much more likely to achieve their targets than those who simply state their goals. His stuff is worth a read!
Studies show that teams using SMART targets are much more focused on achieving their goals. Individuals understand what their goal is, as well as exactly how and when they are going to achieve it, they are therefore more likely to focus on completing the task required and achieve the overall goal.
SMART targets fit perfectly into the software development cycle and most project management methodologies. Effective teams will break development up into short sprints, at the start of these sprints decide on what they are looking to achieve. Teams design SMART targets in order to decide exactly how they are going to achieve their goal as well as whether or not their target is achievable.
SMART targets may also lead to higher customer and end user satisfaction, part of designing a SMART target is ensuring that your goal is relevant, this allows your team to ensure that what they are working on is relevant to the "customer’s” needs.
Are there are drawbacks to SMART targets?
Whilst SMART targets are widely considered the most effective goal setting method, like everything, there downsides.
In IT Project Management, you may have to guard against SMART targets limiting creativity, especially when developing software intended to disrupt. Teams usually decide on a method at the same times as agreeing their end goal and once agreed SMART targets don’t always allow for changes to be made. This prevents scope creep from occurring, which is good, but sometimes scope creep can allow teams to explore new ideas and innovate their software.
Most research shows that SMART target, while great for sprints, are less effective for long term goals. Therefore, IT project teams may need to look at other goal setting methods for more 'overall goals'. However, as previously discussed, when you break overall goals into manageable work units - SMART is king!!
You should also be cautious when deciding on overall goals and deadlines. When used incorrectly, for example setting unrealistic targets (like short deadlines), SMART targets can place too much stress and pressure on team members and eventually lead to project failure, it's much better to allow your team a few extra weeks to perfect a piece of software rather than forcing them to rush and produce a poorer piece of work.
Writing all of this feels like I'm teaching your Granny to suck eggs! You know all of this! I know all of this! However, with IT Project failure rates as consistently high as they are, maybe we need to remind ourselves of some of these basics. In the opening, you read that some teams are just too busy working in their projects to work on them and while I understand this, it is also short sighted in the extreme. Project basics are like the plants in your office, they need to be watered daily and fed once in a while otherwise you look up one day and find that they've withered and died!
The most basic, common and therefore ordinary goal of EVERY IT Project is that they are initiated to succeed ... to deliver business need or facilitate change. That's it! Simple. IT Project success is therefore not a mystery but a series of basic, common and ordinary things that are all done extraordinarily well.
Treat yourself to some thinking time this week, if you are struggling with your IT Projects of late, is there a project management 'basic' that you need to water!
Find out more about Project Management as a Service from Stoneseed
We just moved house and the process wasn't without its fair share of drama. You'll have been there yourself: the viewers who have just come for a nosey; the offer that pulls out just before exchange; the weak link in the chain breaking; the anxiety over whether you're making the right move (a friend bought a house off a farmer a few years back and it was only after she moved in, that the farmer moved his herd of cattle into the quiet field next door!).
The whole process reminded me of the value of subject matter experts. Whether you’re moving home or delivering a market-disrupting piece of software, it pays to have the best resources at your disposal.
As I alluded to, we were all set to go at an earlier stage. The offer on our dream home had been accepted and we were really excited! The sale of our house was progressing nicely, in fact, the whole chain seemed robust. Then ... our buyer pulled out. We were crestfallen and more than just a little anxious: would we be able to find another buyer in this current climate; would we do it in time to keep the hopes of moving to our dream home alive; did we have the stomach for more nosey neighbours having a free tour of our house?
The estate agent didn't seem crestfallen, they didn't seem overly anxious. To us, a buyer pulling out of a house sale is a once or twice in a lifetime event, a huge drama, to them, it was a bread and butter, a regular occurrence. They assured us that they WOULD find another buyer and they were infectiously calm as they set about doing what their years of experience had prepared them to do. The fact that I am writing this from the kitchen table in our new dream home is testament to how true to their word they were.
The solicitor’s work seemed to be done in the blink of an eye (now there’s a profession that doesn’t mess about!). No fluff, no fat!
Then there is the removal firm. I think, chatting to friends, we paid a little over the average for the removal service - but what a service! My wife and I have been together for many years and raised a family. You accumulate a lot of stuff and much of that stuff is highly breakable and highly valuable, not just financially, but sentimentally too.
When the estate agent called to say they had found a new buyer and that the whole process was not only back on but able to proceed at pace, we had to make removals arrangements quickly. I'd been super cautious about booking a firm and fixing a date in case things fell through and, although this had been proved to be a good decision, I was now left with a dilemma. Is a removal firm that can move you at such short notice any good, I wondered, I mean, if they have vans and men sitting idle - is that a warning flag?
I needn't have worried. The firm we hired had short notice capacity, and not because they weren't any good but because they were GREAT. They turned up with their "A-game", the vans were spotlessly clean, the staff were polite and well turned out and nothing was too much trouble. They dismantled furniture at one end and reassembled it perfectly at the other, placing it exactly where we wanted it to go. The breakables were packaged and transported with such care that it was as if they were the removal guys' own. Bulky furniture seemed to almost magically load itself, in fact, in the time that it took me to make the lads a brew, they had emptied our living room and secured its contents safely in their van.
As they left, they wished us good luck in our new home and you really felt that they meant it!
The point is, that any of these services could have been done by ourselves. I deal with contracts on a daily basis, I have years of sales experience so 'finding buyers' is second nature and I have two strapping young lads who could have helped me to load a hired van. I could have done it all, probably, maybe, but I could not have done it all quite so well or quite as quick.
IT Project Management also benefits from the expert touch and you can get this with resources and talent from the Project Management as a Service (PMaaS) market.
The list of what you want from an estate agent, solicitor or removals firm is pretty much the same as a list of what you'd expect from buying in services to bolster your IT Project Management capability.
1) Skills and experience
Using PMaaS, you can access talent with the specialist knowledge that you need for a particular project. I know how to lift a settee onto a van, but the removal guys did in such a way that our whole living room seemed to take up no space at all in their van! And all while I put the kettle on. Many IT projects fail entirely or at least fail to realise full potential due to a lack of experience or skills within the team. It makes sense that a Project Manager, who is idly waiting for a project to manage, should be given the next one that comes along, they are earning a salary, after all. But when your PM, for instance, lacks key skills needed for a particular project, it starts to make less sense and can soon turn into an unmitigated disaster!
2) A sense of urgency and tenacity
Removals firms and hired in Project Managers and resources have something in common. They can’t afford a day when they are less productive, an off day is NOT an option. As I once wrote on CIO.com. "They want to get in, get the gold and get out...and move onto the next project”. That makes commercial sense for you and for them – but they don’t cut corners, because their next job depends on the reference that you give them.
3) Efficiency (cost-effectiveness & productivity)
I suspect that if we HAD decided to move ourselves, we'd either still be doing it or by now I'd be gluing bits of furniture back together. I certainly would have spent the first-night rebuilding beds. Instead, on the first night, we found the local fish and chip shop and sat at our dining room table eating them like we'd lived there forever. Similarly, with expertise bought in via PMaaS, not only do you just pay for what you use, you get to tap into expertise and experience when you need it. And when you no longer need it – it isn't sitting on the bench burning a hole in your payroll. Larger scale or more complex projects require more experienced Project Managers, and they come cheap. Having such pricey talent on your books but idle (between projects) can significantly impact on the overall cost-effectiveness of your PMO. You wouldn’t have a 7.5-tonne lorry sat on your drive in case you decided to move house!
I have not yet come across a Project Management challenge that would not lend itself to accessing Project Management talent, in the same way, that you are buy in other IT resources, from Platform to Infrastructure to Software, or, for that matter, estate agents, solicitors or removals guys ... as a Service.
The real value of experts is measured in the end result, whether that is an IT Project delivered on time and within budget, like I am now, or sitting in your new home with a glass of red wine wearing your slippers. Cheers.
Find out more about Project Management as a Service from Stoneseed
It was written by Fred Brooks in 1975, in his book 'The Mythical Man-Month'.
It is a 'law' that I've always believed to be fundamentally flawed and ripe for breaking. The fact that it is still quoted in 2019 is a cause for major concern to me AND yet, there I was recently on a conference call with a Project Manager friend as he begged for extra resources to bring his late project home and one of the C-suite suits quoted this 1975 'law' as a legitimate reason for refusal.
"The Mythical Man-Month" is actually a really good read but like most things written in 1975, parts of it have stood the test of time and some of it is less relevant now than it was then.
"Fawlty Towers" was first aired in 1975 and I laugh out loud at most of it and cringe a little at others - the stereotype Irish cowboy builder O'Reilly, for example. Things move on, attitudes and tastes change. "Bohemian Rhapsody" and "You're My Best Friend" from Queen's 1975 album 'A Night At The Opera' still sound as fresh as the first day I heard them. "Lazing On A Sunday Afternoon" from the same album, on the other hand, sounds really cheesy now!
The point is that, in 1975, Project Managers considered time as one of the three key external constraints imposed on a project and most gave it equal billing with other constraints, namely scope and cost. You'll have seen the triangle, sometimes known as the triple constraint, with time on one of the three sides and scope and cost on the others. The project management triangle or iron triangle was probably a huge part of your project management schooling. The belief being, that you cannot alter one constraint without changing at least one of the other two. Over time other constraints namely quality, risk, and resources were added but somehow, for many, this limiting belief remained that chasing one constraint would impact the others and have an overall detrimental effect on the project.
Brooks' law was written in the days before Project Management as a Service was a thing. The PMaaS universe is forever expanding and I have yet to find an IT Project challenge for which there is no PMaaS solution. Brooks' law, actually the whole concept of constraints, doesn't reflect the state of the profession now. Imagine playing football by the rules, laws and technological capabilities of 1975, the goalkeeper would be allowed to pick up a back pass, a challenge from behind (that would see you sent off now) would be perfectly acceptable and imagine relying on 1975 action replay standards to make a VAR decision - "we can't see if he's offside because of the large flashing pixelated R"!
These days, most IT Projects have a very real, strategic business value attached to them. IT Projects deliver business change in highly competitive industries; an IT Project must deliver the maximum return on investment (ROI) and deliver it as soon as possible.
For me, it's time that Brooks law was repealed! In fact, it is time that we reframed all those traditional project management constraints and looked at them with fresh eyes. In a world where PMaaS does exist there is no need to accept constraints in their traditional limiting sense. The pick two principles, which suggests that out of any given trio of desired qualities or expectations, only two can co-exist can be confined to the past with this simple reassessment. Traditional thinking that your project might be delivered quickly and inexpensively, but the quality will suffer, can be dismissed when you manage without constraint.
As we have mostly discussed it, let's start by reframing the 'time' constraint.
Do we agree that 'Time is money' and if the monetisable deliverables from your IT Project are delayed, the ROI is also delayed, and the real cost of your project soon starts to build?
It's like a taxicab meter when you're stuck in traffic, Brooks' law would tell you that adding an extra human resource, an extra driver, would not speed up that taxi journey and would not get you to your destination any quicker. That does make a bit of sense, but what if the extra human resource you added was a navigator, someone with increased knowledge of the city's back streets? What if the extra resource were a chap on a motorcycle who pulled up alongside your cab and offered you his spare helmet? What if a helicopter landed in the adjacent park and the pilot offered you a ride? You'd most likely reach your destination on time with these added resources.
It's about adding the right extra human resource and thanks to PMaaS there is an abundance of the exact talent that you need. Brooks' law has never been more untrue. When you have a trusted PMaaS consultant, one who gets to know you and your projects, the PMaaS universe opens up unlimited solution space. Adding an extra human resource, adding any kind of extra resource can have a hugely positive effect on your project.
When you reframe Project Management thinking in this way, time, scope, costs, quality, risk and resources are no longer constraints they are metrics, yardsticks by which capacity and capability can be measured and key areas that can be improved.
Usually, an IT Project is green-lighted to generate profit or to facilitate some business change. Any delay in delivering the end result of your project can increase the time to market and lead to a reduction in or stalling of profits, there is no room for any kind of constraint.
One word of caution. Naturally, scope is still one to watch, you don't want your project sponsor to get a whiff of the fact that you are managing without constraint and hand you a list of extra deliverables that they expect for the same cost and within the same time. Scope still needs to be guarded, that said, I have worked with teams who have used PMaaS resources to deliver extra client demands without increasing overall project portfolio costs - so don't close your mind to saying yes to scope change requests.
The world is very different now to when each of those project management constraints were first conceived, and it is constantly changing.
Truly now, in this PMaaS era, the only Project Management constraint is yourself and your team, the only limitation is your imagination and your willingness to explore new ideas and resourcing options.
Find out more about Project Management as a Service from Stoneseed
Source: The Mythical Man-Month by
In this piece, let’s focus on Six Sigma.
Six Sigma. What Is It, When Should You Use It?
Like a fine wine, it would appear that the Six Sigma methodology gets better with age. Since its initial introduction in the 1980s, fans of the methodology claim that it has been ‘perfected’ thanks to small tweaks that have been made over the years. Six Sigma allows for high-quality deliverables to be produced. Indeed, the main focus of the methodology is to produce a piece of software that is effectively bug-free and teams that use Six Sigma are renowned for producing high-quality work.
In the introductory piece on IT methodologies I wrote the following:
Six Sigma was first introduced in the mid-1980s at Motorola. I believe that executed right, Six Sigma is the best methodology for eliminating errors and therefore improving quality. Six Sigma identifies what is working well and more importantly what is not - what is not working can then be removed from your project's gene pool. Data is key to Six Sigma.
When Is It Most Effective? Six Sigma is great for larger organisations seeking greater efficiency and quality.
Proponents of Six Sigma are among the most passionate advocates of any methodology (as anyone who knows a Six Sigma Master Black Belt will attest). Not for the faint-hearted, data is the lifeblood of the methodology and what you get out of it relates precisely to the quality of what you feed in!
Six Sigma is great for clearly identifying and framing the problem that your IT Project seeks to address and its goals.
Now, let’s do the deep dive on Six Sigma.
What Advocates of Six Sigma Say
Increased quality of software - The majority of teams who chose to use the Six Sigma methodology do so in order to improve the quality of the projects they deliver. Six Sigma practically ensures that software delivered is virtually bug-free, the data analysis used in Six Sigma helps prevents bugs from occurring (usually before an issue has even arisen). Six Sigma makes sense from a business point of view, a higher quality product is more valuable commercially and reputationally.
High customer satisfaction - Teams who use this methodology often boast that their ‘customer’ and stakeholder satisfaction is higher. It’s all about that higher-quality end product. High satisfaction levels payback time and again, happy sponsors and stakeholders mean more project green lights. Better projects mean better end customer experience, yielding a higher number of returning customers for the parent organisation.
Improves team efficiency over time – Every process that takes place during the production of a piece of software is documented, when using Six Sigma. Everything from the processes used, errors that occurred and what steps were taken to resolve these errors. Documenting processes can allow a team to become more effective. The success of a certain process will be documented, the team can then use this as a template for future projects. A good team leader may also use Six Sigma documentation to determine any weaknesses in their team, and allow them to address these issues. For example, they may plan sessions that focus on a specific skill. The Six Sigma documenting process also allows teams to record how they resolved a specific issue, making a fix much simpler in future projects. This could prevent both time and money being wasted in future projects, increasing the efficiency of the team.
What Six Sigma’s Detractors Say
Requires specialist leadership - Whilst most methodologies require an experienced leader, Six Sigma requires a specific type of leader in order to be most effective. Six Sigma courses are available to those looking to lead Six Sigma based projects. Completion of these courses allows individuals to become certified, the higher the certification of an individual the higher their skill set is. Certification ranges from yellow belt to master black belt. The issue with this is that the highest certified individuals are in high demand, making them hard to find and attract to your company. Another obvious issue is pay, as these leaders are in such high demand, companies often pay more to secure their services. On the flip side, securing one of these certified individuals can bring many advantages to businesses, for example their decision making and problem-solving skills can make projects run much smoother. You get what you pay for! The Return on Investment (ROI) from Six Sigma can be higher.
Demanding and complex process - The process of a Six Sigma project can be extremely demanding as well as complex, and this can have a negative impact on team members. Firstly, team members must constantly collect and analyse data in order to produce the information required for the project to be successful. This constant data collection can put stress on team members. This process is also extremely time-consuming. In order to ensure that gold standard data analysis is carried out, teams must dedicate a suitable amount of time to deal with the data collected, this can extend the length of projects, therefore again placing demand on those within the team. Data analysis under Six Sigma considers large amounts of data at once, therefore those carrying out the data need to be experienced with working with high volumes of data at once.
Increased production costs – As touched on already, following Six Sigma can increase the production costs of a project. However, when looking to produce software and outcomes of higher quality, it is often a price worth paying. Those experienced in Six Sigma projects will likely demand a higher pay packet in comparison to the ‘average’ employee but don’t be put off by the price tag – the Project Management as a Service market can deliver Six Sigma benefits without having to add Six Sigma salaries to your payroll.
If you nail it, Six Sigma is the Rolls Royce of the project methodologies. Ultimately, which methodology you choose should depend on the delivery value it will bring. The whole point of your project is to deliver the greatest impact for your business or organisation when you transition your IT Project into service while deploying all resources, you have available in the most efficient manner possible. Six Sigma is a black belt at this!
You should never limit your potential outcomes by sticking to your safe, default, "old faithful" methodology. If you find the best approach is outside your current comfort zone, buying in project resources, from individual talent to end to end PMO, can help you mix things up and reap the rewards of doing so.
Find out more about Project Management as a Service from Stoneseed]]>
Now, I've treated wasp stings with calamine lotion in the past, and I have applied an ice-cold compress, but the apple cider vinegar was a new one on me.
Within seconds, the swelling had gone down and the stung customer was back enjoying his pint.
I asked the waitress where the idea for apple cider vinegar had come from and she just smiled and said, "Life experience."
IT Projects are like this pub beer garden. One minute you're sat enjoying the peace and calm and the next you feel a seemingly unprovoked sting as if from nowhere, that leaves you in agony. Knowing how to treat these IT Project pain points is equally down to life experience - sometimes you need help from a passing waitress or in this case, a great IT Project blog.
Five IT Project Stings and How to Make Treat Them
1) The Sting: Scope Creep
You have the work planned out, resources allocated, everyone knows what they're doing and when and then ... the client changes the requirement or thinks of something that "it would be nice if" your project could deliver. It's really common for client requirements to change and with your "can do" attitude you will try to accommodate. The sting here isn't just the extra work that you will have to fit in, you have to take time to properly understand the client's changed need and then reassess resources, decide who will complete which tasks and communicate all this with your team.
From the start, define, agree and then stick to a scope change approval process. Make sure that there is an understanding that mid-lifecycle changes will also probably lead to changes to cost and timings. When a change is requested, detail all the requirements that have changed, list everything that the client has requested and communicate to your client how these changes will affect the scope, cost and delivery date of the project. You can also set and agree response levels based on time and cost, effectively approval filters for requests, so easily accommodated changes can be actioned by without senior approval whereas changes that need extra cost, resources or time must be passed to a senior project leader for approval.
Pre-agreed parameters take the awkwardness out of any change request. Thorough cataloguing gives you and your project stakeholders a quick reference point to check and communicate scope change.
Finally, the Project Management as a Service market is great for taking the sting of scope change, the extra, on-demand resources that PMaaS can offer give you unlimited response options.
2) The Sting: Miscalculated Time Estimates
How tight are project deadlines these days? Everything in tech is moving so fast! Clients want delivery and return on investment as quickly as possible. This can sometimes lead to hurried and, therefore, unrealistic forecasts. You don't have a crystal ball, you can't predict everything that's going to happen. Like planning a road journey without factoring in traffic delays, accidents, red lights and roadworks - great if you have a clear run but the smallest delay means you'll arrive late.
"Cut yourself some slack", I often hear this from teams at the point where poorly estimated time forecasts are causing pain, they mean it in the sense of "don't beat yourself up about it". Actually cutting yourself some slack is a great preventative measure. Back in the day, cutting yourself some slack meant giving yourself more rope than you think you'd need on a sailing boat. For plain sailing in your IT Project, build in a time buffer on each task so that if one element is delayed it doesn't impact your final delivery date.
If unrealistic time pressures are being imposed by unavoidable end client or organisational demands then consider bolstering your resources with PMaaS back up.
3) The Sting: Lack of Transparency
I remember reading a post mortem on a failed IT Project some years back that described the project's transparency as "opaque". It actually made me laugh and I've never forgotten it. It's really important for Project Managers and stakeholders to be able to get a view of how the project is progressing, where each task is at, who is doing what, etc. Every project team will tell you that this is what they have but this never really gets tested until someone actually needs to take a look. It's like thinking that car your engine is running well, then it fails and you need pop the bonnet to take a look, only to be met with plumes of smoke.
A task management tool allows quick access to the progress of your project, and the best project management software products give real-time updates which let everyone keep a check on where the project is at - without having to gather everyone around the water cooler for a catch up. You know all this though, and I know all this too - so why does it sometimes fail?
It's what I call the "Sunday Night Homework Trap". Remember, at school, you'd be set some French homework that had to be handed in two weeks later? When did you do it? That night? Or was it the night before it had to be handed in? Honestly, when I was a kid, "Last Of The Summer Wine" used to come on the telly on a Sunday and I'd think "Arrrgggh! French homework."
So the key is to actually fill in the information required for full transparency at the earliest possible moment - out of date progress reports can cause as much "project panic" as actual, real problems, so develop an open culture and make filling in the data fields in your software package a daily habit.
If this is a struggle consider turning to your PMaaS partner for end to end Project Management Office which will come with transparency built-in!
4) The Sting: Lack of Accountability
Accountability isn't (just) about deciding who is to blame when something goes wrong, but it often carries this negative connotation and this may be the reason why project leaders sometimes fail to create a culture of accountability. Finger-pointing isn't great for team spirit, so accountability needs a rebrand.
Being accountable means being a team member who can be trusted, accountability means being willing to accept responsibility for your actions (and the plaudits when your actions make you into a hero), accountability means that you don't have to have your project leader stand over you all the time to make sure you're nailing it! Some project leaders are caught in the "accountability means blame" trap so find it hard deciding who is responsible for what, especially when there are multiple team members working on the same task.
Some teams are just too close-knit and friendly for individual accountability to deliver fully, the ‘we're all in it together attitude’ is great as long as having your colleague's back means helping recover after a mistake, not cover it up. In my experience, teams without proper accountability are often ones where a project leader has risen through the ranks to a senior position and now finds it awkward holding former colleagues to account.
Create a culture where it's OK to fail, to err, to miscalculate, to get it wrong, to be human - as long as you are open and honest and take the best action to put things right. In cultures like this, it's amazing how everyone does have each other's backs and pulls together for the greater good. In cultures like this, it is also easier to assign responsibility because doing so doesn't feel like you're setting a colleague up for a carpeting later on.
Accountability needs to be clearly established from the start, without any room for misunderstanding, and this way all parties deliver the exact responsibilities given to them.
Again, Project Management as a Service solutions, like end to end PMO, can take the heat out of accountability, especially in teams that are too close-knit or where a former colleague is now the leader. External resources don't worry about internal issues or as one colleague puts it "the rudders on the wings of a plane don't care about the baggage on board, they're too busy steering the plane."
5) The Sting: Misinterpretation / Miscommunication
Another area for problems is when stakeholders and end clients misunderstand IT-specific terminologies, protocols, methods and concepts. I have a rule that if the client has a false understanding of IT project deliverables, personnel, methods, or tools - then this is our (the project team's) fault. Unrealistic project expectations and assumed deliverables really leak perceived value from your delivered project – so communication is key.
An IT project manager must liaise with the client in order to help them understand what exactly can and will be achieved and more importantly (perhaps) what cannot and will not. Sometimes we assume that everyone is as clued up as we are about the workings of our IT Project, especially stakeholders, sponsors and clients who surely have a vested interest! The truth is that they do have a vested interest but only in the result and the delivered project. They don't care how it comes into being, no more than you care how a plane takes off and stays in the air, you just care about getting to Lanzarote! An educated client, ultimately, is a happy client, they don't need to know the workings of Waterfall or Agile, but when they are clear on what they will and won't deliver, your job becomes a lot less stressful.
Before I buzz off then, to conclude, the quicker you identify pain points within your IT Project the quicker you can deal with and get past them. They can and often do blow up just like wasp stings, they cause pain, irritation and discomfort and in rare cases, they can even be fatal.
As always, prevention is better than cure, talk with your Project Management Services partner, arrange a review of your portfolio, initiate a gap analysis and discuss what options are available in the ever-expanding PMaaS universe.
That guy in the pub garden left with an arm still smelling of apple cider vinegar, how much better to prevent being stung in the first place?
Find out more about Project Management as a Service from Stoneseed]]>
Having looked at Waterfall and Agile, let’s now turn to Scrum.
Scrum. What Is It, When Should You Use It?
Normally, when you talk of scrums you think of a bunch of well-built players, huddled together and yet working alone to achieve their goal – a rugby scrum. In IT Project Management, when thinking of scrum, one word jumps out and connects the two nicely - Interlocking.
In rugby, players will interlock with one another and push against their opponents in an attempt to win possession of the ball. IT teams who utilise the scrum methodology rely on five interlocking values, these values are relied upon when developing software.
In the introductory piece, I wrote the following on Scrum
I've deliberately placed Scrum just below Agile. Many Project Managers don't see Scrum as a stand-alone methodology but instead a branch of Agile thinking, Scrum certainly offers more solid stepping stones to the Agile manifesto.
Scrum is based on the values of ...
Whether used alone or as a hybrid Agile approach, Scrum adds to the iterative value of Agile and, used right, can add increased transparency, governance, accountability and collaborative value.
When Is It Most Effective? Great for mid-sized to smaller teams who need (paradoxically) both greater flexibility and greater structure.
Scrum is built around key roles. The Scrum Master ensures execution based on Scrum principles, the Product Owner is the representative of the stakeholders and the Development team who, well, develop and deliver the product.
Delivery is broken into events, such as sprints, giving a clear and transparent real-time view during the project lifecycle.
The sprints are at the core of Scrum's success. In "The 5 Scrum Values", Mark C. Layton writes "The sprint requires clear goals set within fixed time boxes. The good news is, in this model, you break down those goals into the smallest chunks of work possible so that you know what you’re getting into. You’ll know what “realistic” is, so you can set appropriate goals and meet your commitments."
What do advocates of the Scrum methodology say?
Extremely flexible - As Scrum is considered a branch of the Agile methodology it shares many similarities in terms of its advantages. One of those advantages is its flexibility. As previously mentioned, scrum projects are broken down into short ‘sprints’, this makes problem-solving much simpler. At the end of a sprint, any minor issues can be identified and rectified, this ensures that developers aren’t left with a large number of issues to solve towards the end of the project. Change is less demanding when following the Scrum methodology, it is much easier to make changes to small sprints then it is to make changes to a larger sprint, this, therefore, allows developers to take a different direction of thinking if necessary.
Clear Visibility – Progress in IT projects can be clearly tracked by the scrum leader. Scrum-based teams will regularly meet in order to discuss the progress in which developers have made. These meetings allow teams to ensure they have fully completed the previous sprint whilst planning what they aim to achieve in the following sprint. Any issues that have arisen during the previous sprint should also be discussed during these meetings, allowing the team to discuss problem-solving techniques. Consumers should also be regularly invited to provide feedback during these meetings. Feedback should include any problems they are having with the software as well as any features they would like to see implemented in future updates.
Great For Goal Setting / Milestone - As previously mentioned, at the beginning of sprints the scrum leader should meet with the team in order to discuss and plan what they aim to achieve. During these meetings, the leader team should discuss their overall aim for the coming sprint as well as what is expected of each individual. A good scrum leader should be able to evaluate their team in order to understand their limits, this will also for them to set their team realistic targets. This will ensure that targets push the team to work hard without overloading them with work, thus forcing the team to sacrifice quality in order to complete the large quantity of work set.
Increased Staff/Team Motivation – As goal setting is a commonly used tool within Scrum teams, this, in turn, breeds greater morale. Latham, a well-respected psychologist states that ‘The setting of goals has been shown to increase employee motivation and organizational commitment’. His research has found when employees are presented with a goal to work towards their work rate increases. Scrum teams do often seem to be more motivated to complete tasks and therefore often complete the development of a piece of software, for example, more efficiently.
Teams working with Scrum methodology are also likely to feel more valued in comparison to other methodologies. Each team member understands that they have a role within the team as well as a set of responsibilities; the fact that they have individually been assigned a particular task usually motivates them to work hard to complete it. There can also be a really useful competitive edge to scrum as individuals strive to deliver first or at least ensure that they aren’t the only member of the team who has failed to complete their part of the sprint.
Again, a good Scrum leader should be able to identify the strengths and weaknesses of those within the team in order to ensure that employees aren’t assigned a task in an area which they are weaker.
What Do Scrum’s Detractors Say?
Intense Process – As previously stated the lifecycle of scrum projects consists of short sprints that constantly follow one another until the end of the project. This constant cycle of sprints can be extremely intense, especially in projects that have a set deadline. Whilst having a goal to work towards can motivate teams to work hard, in some cases these goals may become a burden to either the team or individual members. Team members are under constant pressure to achieve their individual tasks, this pressure may begin to place stress on team members. In some cases it may also lead to teams rushing their tasks in order to complete them before the end of the sprint, most likely leading to a reduction in the quality of their work.
In order to avoid this, the scrum leader needs to ensure they set realistic targets for their team in order to ensure that the team aren’t overworked during a sprint.
Increased Risk Of Scope Creep – Scope creep, when a project’s requirements increase over its lifecycle, can be more common using Scrum. In a recent case, a team that originally set out to deliver one instalment of software finished the project having delivered multiple instalments. This fact had been “lost in the sprints” and the project delivered late. The risk with short sprints, like short sprints in real life, is that if you’re sprinting in the wrong direction, you can quickly veer way off course. Check you’re sprinting in the right direction.
Scope creep is often caused by the end client changing their requirements, however, it can also occur as a result of miscommunication within the team. Scope creep can be overwhelming, especially for in-experienced teams, projects without delivery dates may appear never-ending, and in the intense round of Scrum sprints, it is crucial that you identify that each sprint is aligned to the overall goal and not an offshoot that leads the project off course.
In order to combat scope creep, a helicopter view of the project as a whole is crucial. Processes for agreeing change are essential and scrum leaders should also ensure they remind their team that change is normally a positive thing. It can be demotivating to feel like you’re suddenly working on something that wasn’t in the original plan, a change in direction can be frustrating, and communicating that it will allow your team to ensure their project meets the changed needs of their consumer, thus allowing them to create a more effective piece of software, can help with morale.
More Experience Required – As touched on several times already, Scrum will most likely not work for in-experienced teams. It is vital that the scrum leader is experienced, they need to be able to asses the ability as well as the strengths and weaknesses of their team, this will allow them to set their team effective targets. Experience amongst team members is also vital for Scrum to work effectively. Experienced members will have developed the skills necessary for Scrum projects to be successful, for example, communicational skills. Experienced teams will have also developed time management skills, allowing them to understand the amount of time they need to dedicate to a particular task. This will allow them to plan each sprint in more detail, for example planning how many hours/days can be spent on a particular task, sticking to this schedule should see the team complete all of the tasks within the sprint to a good standard.
In conclusion, as with all IT Project Management methodologies, the benefits significantly outweigh the risks – if you do it right and have the right people on board. Don’t discount Scrum if you are lacking experience in your team, resources from the Project Management as a Service market can fill gaps and allow you to benefit from the many advantages it can offer.
Find out more about Project Management as a Service from Stoneseed
And you begin to ask – have we missed something?
The answer is almost certainly ‘yes’.
At Stoneseed, transition into service is an aspect of the project lifecycle that we are increasingly helping with clients with and this “reluctant customer” or “reluctant stakeholder” phenomenon is one that we are seeing repeated on a regular basis. It’s like getting to the edge of the penalty box and being afraid to shoot, procrastination at the delivery end of IT Projects is on the increase.
As a Project Leader, you have a number of options here. The most popular two are, as a project manager friend poetically calls them, the "Bulldozer” and “Butterfly" approaches.
She told me, "The bulldozer approach pretty much does what it says! You have other projects waiting, you've spent blood, sweat and tears on this project! Testing is going well, ok there are a few bugs, but you've delivered projects before and sorted niggles after the 'go live' day. So you use your persuasive skills to convince the client that it's just 'opening night nerves' and that the project needs go-live. NOW!"
The problem with this approach is that it's not win/win. OK, you got what you want, the project is signed off and transitioned into service but what about the end client? How do they feel? Bullied? Railroaded? And what about the end-users who have to put with buggy software? Are they happy?
And ultimately, what about your team? Can they really move on when they keep having to field support calls post-delivery?
Years ago, a wise IT Project leader once asked me, "If you deliver your project, and it doesn't bring the full impact to its users on day one, have you really delivered the project at all?"
So, what of the “butterfly” approach?
"The butterfly approach is altogether less heavy-handed. You've heard of taking a helicopter view, you can visualise exactly what's meant by that, so hold that thought. Swap the chopper for a delicate butterfly though. Same job, it takes an overview of the project from a high viewpoint but because it’s smaller and more delicate it can also really zoom in and check very specific parts of the project for issues that may have been missed. You'll have seen a butterfly land on the buddleias - imagine a helicopter doing that!! It would blow it everywhere! No, the butterfly gently lands on a single flower, does its job and leaves the rest of the plant unaffected. The attention that you give to your IT Project at this point in its lifecycle needs to be just as delicate, just as precise and just as non-destructive to everything else you've created."
So, let's park the bulldozer. How does the butterfly approach work with your reluctant customer?
"At this stage, the quality of the outcome is based upon the quality of your questions. The best project leaders direct this crucial conversation by only asking questions. It's a hard skill to learn because every sinew of you wants to get defensive and scream that you've delivered what's been asked of you! Stay calm and just ask questions AND take notes!"
Questions like ...
When they voice a worry ask, “What do you mean by that?” And after they've answered ... ask what they mean by THAT? (Drill down! Often the gold is in the answer to the third question).
What are their concerns? What would a solution to their concerns look and feel like? Who has expressed the concerns? When did the doubts start? (This can sometimes really help you pinpoint a specific time when confidence was lost and gives you a great target for that butterfly!)
Has something changed within the organisation? Is “regime change is in the air”? It happens with a cabinet reshuffle doesn't it, all the best-laid plans go out of the window as incoming Ministers seem to find new money for new initiatives. Businesses are the same, whether it is a promotion that opens up new possibilities, or mergers, acquisition, company sales etc, they all bring with them a large portion of uncertainty that can unsettle decision making.
How is your client contact and their end-user team feeling about their ability to use the project once it transitions into service? Get a sense for any doubts about end-user capability. Ask if there are post-delivery capacity issues. Do they trust the project's ability to deliver the business need? Do they trust their ability to make the project to deliver the business need? Can they handle this project if it were to go live now? Basically, there may not be a problem with the project, but you could spend weeks looking for one and fixing things that didn't need fixing when all that was needed was some extra staff training!
Often, when you take time to listen, REALLY listen, your end client will identify the thing that is missing for you and it can be something as simple as a requirement, a function or a report that can be easily accommodated. The key then is to agree on how to proceed. If it's an easy fix - do it! If it's something that you missed - admit the oversight and do it! If, on the other hand, it's a large piece of work that's needed, advise any extra costs, timeframes, etc. If it's an internal stakeholder, ask them to suggest which other business projects should be delayed to accommodate their new requests - actually take them to your whiteboard (or digital equivalent) and ask them to choose which other business manager's project should be delayed to extend theirs.
Prevention Is Better Than Cure
Most project teams start this process at such a late stage that it almost always causes delay. The trick is to unleash your butterflies regularly during the lifecycle so that you can spot possible issues and deal with them.
Also, maintain a culture that is receptive to feedback throughout. These days, IT Projects are more transparent than ever and most of the popular methodologies lend themselves to you being able to pop the bonnet once in a while to show your client how things are working. Have regular catchups and solicit feedback at key milestones or whenever is suitable. If you were painting someone’s house, you might just do a patch and then ask the homeowner what they think before climbing the ladder and attacking every wall with your paintbrush. Same with an IT Project - don't leave it till the job is finished to find out they no longer like pink!
So, the reluctant customer shouldn’t be seen as a frustration – see them as wanting to give valuable feedback (albeit late in the day). Listening to and acting on client concerns usually means that you deliver a better project, more in tune with the business need and that plays out well when seeking commissions and green lights in the future.
Agile. What Is It, When Should You Use It?
The story goes that seventeen software thought leaders, programmers and developers met at The Lodge at the Snowbird ski resort, in the Wasatch mountains of Utah. They skied, ate, and talked. What came out of those two February days would be ground breaking, the Agile ‘Software Development’ Manifesto would change project management - forever.
When thinking of the term agile you think of something that is faced paced and able to change direction in an instant, for example, a Manchester United footballer. The terms ‘faced paced’ and ‘change of direction’ are extremely applicable to Agile projects.
Agile projects move extremely quickly, the methodology allows you to work quickly in order to deliver new software to your clients on a faster or more regular basis. Agile projects don’t literally change directions, but teams do have to make decisions that can potentially change the course of their project, for example, when a particular issue must be solved quickly, Agile suits this environment to ensure that delivery isn’t delayed.
This is how I summed up Agile in an introductory, flyover piece on methodologies ...
Although Agile hasn't been around as long, it is now also considered one of the "old faithful" methodologies. Agile is one of the most popular Project Management approaches and for many PMs, it is their default.
When Is It Most Effective? Where it is advantageous to see incremental deliverables – e.g. software development or to “box” up elements of functionality, build it, review it and amend, or multiple streams at the same time. So, Agile benefits projects that are incremental, evolutionary or iterative and collaborative projects, requiring cross-departmental communication. Agile was created to address some of the perceived limitations of Waterfall and as such it is perfect for fast-moving environments where greater flexibility is key, the most obvious example being software development.
The "Manifesto for Agile Software Development" defines the ethos behind the methodology nicely, placing individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation and responding to change over following a plan. The 12 principles of Agile (more detail in the stand-alone post on Agile) leave users with clarity of purpose but lots of room for creative thinking.
What do advocates of the agile methodology say?
Continuous Delivery And Constant Visibility - Agile allows for a continuous stream to be delivered to your customer. Throughout the project, customers may be ‘drip-fed’ different iterations and incremental chunks, new versions of the software may be delivered continuously over a certain time frame, for example, once a week. With each delivery customers may be given a list that details the various features that have been added during the latest phase of the project.
More effective Short to Mid Term Planning - One of the main attributes of Agile is momentum, it allows a project to run fluidly through the various short-term phases of development. Issues may arise towards the end of a phase, rather than allowing this issue to delay completion developers can plan to resolve the issue in the following phase of the project, this, therefore, reduces the chance of delays whilst ensuring issues are resolved.
Ongoing Testing- Agile allows for modular testing to be carried out throughout a project. The Agile Manifesto states, “Working software is the primary measure of progress,” therefore ensuring any issues that arise throughout a project are addressed is vital. The agile methodology allows for testing to be carried out throughout the project and can, therefore, be rectified. This reduces the risk of issues de-railing a project towards the end.
Rapid Evaluation and Delivery - Agile can also allow your team to quickly produce a fully functioning piece of software in a shorter timescale. Evaluation is fast and actionable increasing the effectiveness of software development teams.
Flexibility And Better Change Management - Change can occur at many stages during a project, whether during planning or during a certain phase of the project and while some consider change as a problem, Agile allows change to happen in small manageable chunks. Smaller changes can also be easily reversed (in comparison with larger changes or when using other methodologies). If the change is not suitable to the project, Agile facilitates quick restoration of previous iterations or for a new, more acceptable change to be made. Overall, these factors ensure that individuals start to see change as a positive rather than a negative.
What Do Its Detractors Say?
Need For Cultural Change - The demands in which Agile teams are placed under are in stark contrast to various other methodologies, this can be an issue for those used to alternative approaches. Agile requires teams to work closely aside one another in a disciplined manner. Teams that are not used to these demands can struggle with this and often a cultural re-frame is needed. In order to counter this, in-experienced teams could be mentored, enabling them to cope with the demands of Agile, whilst also learning the necessary skills.
Need For New Skills - In order for Agile to be successful teams need to possess a set of advanced skills. This is again a key issue for inexperienced teams who may not yet have developed those skills. Teams need to be able to work quickly in a pressurised environment whilst having the capacity to solve complex issues. In order to work effectively within these environments, teamwork led skills, such as communication, are vital to ensure the team works as a collaborative unit. Again, inexperienced teams can be mentored.
Need For Extra Training - Ensuring teams are adequately trained is vital for Agile project success, many detractors point to the fact that insufficient training can lead to an increased risk of failure compared with other methodologies. This is true but could be said of anything, lack of driver training could result in more car accidents but that doesn’t mean you should abandon the car – you stick on the ‘L’ plates and learn. Those that are used to other methodologies often assume that the rules are more relaxed on an agile programme due to the decreased reliance on other development processes. This is however not the case, teams must follow the tasks that are prescribed to them in order to ensure their project is a success.
Clarity Can Be An Issue - Agile is extremely dependent on the clarity given by the client. When a client is clear in terms of their intended outcome your team will have a clear goal to work towards. However, when a client is less clear agile projects may go off at a tangent quicker than other methodologies, if left unchecked. Again, this can be solved by ensuring that your team has experienced members! Experienced individuals will know when further consultation is needed to fully understand the client’s desired outcome and expectations. These consultations gift you the chance to ask any potential questions whilst also gaining feedback from the client and should be carried out at each phase of the programme. Do this and an agile project will remain on track in terms of reaching your client's desired outcome.
There’s Danger of Excessive Risk-Taking - Agile's detractors believe that within inexperienced teams there is a risk of trying to complete too many tasks within one phase of the project, therefore placing an increased amount of pressure on the team. We have all seen over-ambition fuelled by the apparent simplicity and organisation of Agile processes and this is another area where experience is key in Agile teams. Experience teaches you what your limits are and the discipline to plan each phase accordingly.
In conclusion, on balance, I think Agile is the methodology most suited to most project types and probably the best foundation for a hybrid approach. Agile comes with more demands but with proper training and execution, the rewards can be much greater.
Fast forward six months, it's a different story. The shine has worn off, the customer is unhappy, and the previously stable system is now the most hated application in the department.
What happened? Because this does happen!
In most cases where IT Projects go from hero to zero soon after delivery, it is because of a lack of adequate support.
“Each time a query has to be raised the support desk simply do not know what to do with the application and tickets remained unresolved – they don’t who to call!” This is actual feedback I read on an IT project just five months after delivery. End users were forced to create elaborate workarounds. Confidence was lost.
This is how reputations are ruined.
Organisations support their applications differently and IT project teams can address this by reframing the post-delivery landscape and working on the basics of a support service. So, for how long should you support your project?
I remember once, during onboarding, a former colleague asking new recruits, "When do YOU think our responsibility for an IT Project ends?"
The ink would hardly be dry on their freshly minted certificates and the theory would be fresh in their head so almost all would answer that responsibility ended on, or shortly after, delivery.
My colleague would mimic that sound the Mr Babbage computer emitted on Family Fortunes when a contestant gave a wrong answer.
Some would then consider that responsibility might last into a settling in period, or perhaps until customer or end-user training was completed. Again, my colleague would make that iconic television show sound and then smile.
"It never ends," he'd say, adding, "we are responsible for our IT Projects until the day they are superseded."
His thinking was that as long as the application was live, those responsible for developing it should be available to answer questions about it. To be clear, he wasn't advocating 24-7 support or calls from a client at 10 pm on a Sunday night, but he was adamant that having unleashed a solution onto the world, we should at least be answerable for its future behaviour.
Whether it is the handy person fixing the printer, super users you've trained up or an outsourced support desk, all will eventually have one central question: if I can’t work out what to do, who do I call? Who do you think your IT Project end users should be calling? Ghostbusters?
The next question, after who will help, is usually how quickly will they help me? This can become a nice metric by which to be measured. In my experience, most issues can be resolved really quickly and teams that have processes in place to accommodate support questions can quickly raise their profile and become organisational heroes. As long as it doesn’t derail the daily tasks!
IT Projects are our babies, and while some us feel an ongoing instinct to support them, many IT Project teams shut the door once they have flown the nest. It's understandable because, to be fair, there never seem to be enough hours in the day for the work you have scheduled let alone an old project coming back to haunt you.
However, being there in a support capacity builds great relationships.
The thing is, you never know when you might need the good will that you bank by being the one to call upon in a crisis. Your next project may hit some roadblocks and when you need stakeholders to cut you some slack, they are more likely to do so if they remember how grateful they were that you were there in their hour of need.
The third question, asked by end users, is likely to be ‘who else needs to know that we are in a pickle?’
Who does need to know? Put yourself in your end user’s position. They can't do their job one day or their productivity is reduced because of YOUR IT Project, they won't hide this and hope no-one notices - they'll tell their boss. Now put yourself in the boss's shoes. She oversees a team of end users and their IT issues are denting her department's targets - what does she do? When IT isn't performing it quickly shows up on board level radars.
IT is at the strategic heart of business now and with this increased prominence comes increased responsibility. Many are arguing that the lifecycle of a project, that once spanned from initiation to delivery, now extends into the operational period. It is here, when end users are manifesting your project's business value, that they need your support more than ever.
Finally, here's an exciting thought. One of my project manager friends has identified this as a whole new service offer. "Like offering an extended warranty on a toaster," he told me. Extended warranties always come at a premium and he has managed to negotiate extra budget for his team to provide ongoing support beyond what would have previously been expected of his team. Rather than seeing support as a problem or a distraction from his schedule he has creatively negotiated new budget for the IT Project team.
Extra money! Now that's something worth your support!
I’d love to hear your thoughts on this, please get in touch – how far are you willing and able to support your IT Projects.
As IT Projects have got more complex, teams have started to fall into the trap of over-complicating their approach to managing them. Where's Marie Kondo when you need her?
If you haven't heard of Marie Kondo, she is a Japanese tidying guru. In her Netflix programme, she promises that her "KonMari" method will deliver, not only a de-cluttered house but also a clean and de-cluttered mind. I wondered whether this was something we needed in IT Project Management.
So where to start?
1 - Declutter the docs
Have you ever heard a Project Manager complain that they completed a document during a project, then picked up another and found themselves writing or even copy and pasting the same information? They'll say that it slows down productivity and adds little benefit. It’s time to declutter your docs!
Let's drill down a bit on this because Marie Kondo's method of decluttering really works here.
Faced with IT Project docs, she'd say:
iii) Be appreciative. Appreciate the work that went into the creation of a document. Chances are the person next to you spent hours creating drop-down lists in it two years ago.
2 - Inbox zero
"Inbox Zero" is an email management system that means you end each workday with no emails in your main inbox - not even read ones!! Imagine – relaxing just thinking about it, isn’t it! The peace of mind that comes from having rigorously and effectively sorted, actioned, deleted or forwarded every message that pinged during the day is priceless.
It might seem like a crazy, unachievable dream! If you have hundreds (or even thousands) of unread emails, it can start to weigh upon your mind and impact performance. Colleagues who have achieved this inbox nirvana swear by it. The positive effect on their mental health transfers into every aspect of their life. On told me, "You don't wake in the night worried that you may have missed something.”
3 - Have the stuff you use every day close to hand
When decluttering a kitchen, Marie Kondo will recommend that you put the plates you use every day in a cupboard that is easy to get to, meanwhile, that ice-cream maker can probably get stored in a less easy to reach space (we have a cupboard of regret!).
It's the same with IT Projects. We often ask Project Managers on struggling IT Projects to show us how they access the crucial system documents that they use to run their projects. In our experience, few are just one click away from the assets that are the lifeblood of their projects.
"If you have to click the start menu and scroll through your programmes, you're starting your task too late," one PM friend says. "The programmes and documents that you use to run your project should be as accessible as the knives and forks in your kitchen.”
The more successful Project Managers have links to the stuff they use every day on their desktop or pinned to the taskbar and on the first page of apps on their phone!
And this doesn't have to be all work, work, work - if your motivational music comes from Spotify playlist each day - stick that on your taskbar too!!!
That's just three areas that could be de-cluttered. I'm sure there are more. This week take a look at your portfolio, work out what you NEED to manage projects, like we did with Stoneseed's induction pack which consists of the Project initiation document, RADICAL log, Weekly Update, Change Control and Project Plan. Take a look at how your Project Management Office could help streamline document suits.
Ask yourself, honestly, if your working environment and approach could use the Marie Kondo touch.
This is one of my favourite bits of client feedback! It refers to a particularly successful deployment of Project Management as a Service resources.
The email as a whole talks about the effectiveness of the talent, the extra experience and skills that they provided, and how the project would have failed without them. What I really love about it though, is the notion that the project talent "fitted in" thanks to luck, rather than through intentional and meticulous research, assessment, reflection and positioning.
It reminds me of the scene in "The Devil Wears Prada" where Anne Hathaway's Andy sniggers at the Runway team agonising over very similar items. Miranda Priestley delivers a withering monologue about Andy's "lumpy blue sweater" and the concerted efforts behind how it came to be in Andy's closet ... Oscar de la Renta's "collection of cerulean gowns", Yves Saint Laurent's "cerulean military jackets" and eight other designers quickly using cerulean in their collections before, finally, it "filtered down through the department stores and then trickled on down into some tragic Casual Corner where you, no doubt, fished it out of some clearance bin." Ouch!
As Streep says, "That blue represents millions of dollars and countless jobs and its sort of comical how you think that you've made a choice that exempts you from the fashion industry when, in fact, you're wearing a sweater that was selected for you by the people in this room from a pile of stuff."
In the same way, placement of "cultural fit" Project Management as a Service talent should never be down to serendipity. Cultural fit should never be a happy accident. It should be an intended and stated outcome. Talent should be "selected for YOU by the people in this room." It certainly is with Stoneseed and I hope that other PMaaS providers are the same!
Consider this from stoneseed.com, "Project Management as a Service (PMaaS) provides access to project professionals, resources and tools at a flexible and predictable cost. Our services portfolio offers a true end to end service, from IT Advisory, through Programme & Project Delivery to Service Delivery. PMaaS provides access to Flexible Resources on Demand, Project Management Office, Process and Methodology, Tool Sets and a straightforward Cost Model."
Everything in this elevator pitch for PMaaS is vital to the success of your project and your business and at the heart of it all – people. None of this can deliver best results without careful matching of these people with yours and that means knowing your culture.
Writing for projecttimes.com, Paul Oppong says, "Project Management as a Service is not without its risks. Unlike some other “as a service” offerings such as Software as a Service and Platform as a Service, with PMaaS you are buying in the help of people. While people may be very effective project managers, they may not necessarily be a good cultural fit for the organisation ... people working within the culture already are likely to have a better idea of the “way things work around here” and how to get things done. With this in mind, in some cases, it might very well be preferable to gain the required project management competencies in-house."
Paul's article raises some good points and is worth a read but it misses a couple of points:
1 - Organisations using PMaaS do so usually because the competencies they need are not available in-house;
2 - PMaaS partners worth working with prioritise cultural fit. They won't compromise. Cultural 'bad fit' and even 'close fit' talent won't deliver your organisation's maximum required outcomes - so what's the point of bothering?
How do we do it?
First, we get to know you. I mean, really get to know you: your organisation; your industry; your unique story; and how YOU do business. We assess your needs; your in-house capabilities and we identify your capability gaps. Secondly, after careful consideration, we prescribe tailor-made solutions to your specific requirements. YOUR culture is at the heart of that process.
Every business has its own DNA. How you do business might be very different to how your competitor across town operates. Same business - different approach. That's your USP. Your culture and your ethos are key elements of this and should be respected and reflected in everything you do - including PMaaS.
Similarly, every Project Manager has their own unique way of delivering 'standard' working practices. The same PRINCE2 certificates can hang on the walls of two PMs and mean completely different things to them both. How one operates might dovetail beautifully with your DNA whereas the other might jar with it like fingernails down a chalkboard.
Marrying the two together – that is when the magic happens! Why settle for anything less than magic!?
Culture matters. The effects of a cultural bad fit last long beyond a person's time with you - weeks, months, even years! As a CIO friend once put it, "A single bad egg ruins the cake." We are very mindful of this and take rigorous care to ensure that every PMaaS placement is in harmony with the culture and values of the client.
These days, more than ever, IT Projects deliver business goals. For PMaaS to deliver the necessary return on investment it has to be delivered through a partnership between you and your provider. The key to a successful partnership? Your provider has to understand your culture and deliver in sympathy with it. On this, just like Meryl Streep's Miranda, refuse to compromise!
The terminology and the number of phases may differ slightly from client to client but, broadly speaking, most follow a similar model.
As this is a cycle, the really interesting part of the discussion for me is how this is applied to a project in real life. Crucially, how does the lifecycle map onto a project timeline? Where does a project start and finish?
In my experience, project organisations are reasonably good at defining the start point, that stage in the cycle where an idea or concept actually becomes a project.
Strangely, where many organisations are not so good is defining the endpoint.
They know how to get on and how to ride their project cycle, but many don’t know how or when to get off. This means that they either ride off into the distance (never-ending projects are becoming more common) or they lose balance and crash in a heap of twisted pedals and bent spokes.
There are usually a number of reasons that blur the view of project teams at closeout.
1 - Often resources are tight, so the project team have to quickly move onto the next project upon 'completion'.
2 - Maybe the closure phase is seen as less important than the tangible delivery, which is complete by the stage that closeout is beneficial. This can be from both the viewpoint of the project team and also the client organisation. It can be like reviewing a car journey when you've arrived at the destination. What's the point, right? But what if there was another road you could have taken? What if the motorway could have shaved an hour off the journey? What if the scenic route could have provided a more picturesque and inspiring view from your driver's seat.
3 - Attention can go AWOL! Especially after delivering a difficult project! Team members can treat closeout like a footballer might treat a post-match TV interview. That is, something that they have to do but also something that doesn't affect the result (N.B. In IT Project Management this bit of post-match analysis can totally affect the result!!!)
4 - Sometimes, a team fails to plan the closeout phase and is forced to attempt to both plan and execute this phase at the same time which can be like herding cats!
5 - Often, team members begin to leave the team before closure phase is completed due to a lack of understanding of their role in the closeout.
6 - Sometimes, the closeout phase surfaces unresolved issues, unsatisfactory deliverables or uncompleted work but the team has started to disband and so it is left to the project manager and a smaller staff to resolve issues that they themselves may not have had a hand in creating.
7 - Usually, there is a lack of ownership for this phase. It's often not seen as a 'sexy' part of Project Management, so no-one wants their name attached to it! As one PM friend puts it poetically, "My parents run a pub, their name is above the front door as you enter and not above the door to the toilets!"
... by the way, often it is a combination of these reasons that lead to this closeout step being either less effective or discarded altogether.
I am a big advocate of the closure phase, often considering it a crucial part of the actual execution phase. A time where you gather lessons learned, ensure projects are handed into BAU in a structured way, close down budgets, etc. Without this closeout phase, the project team cannot fully move onto the next project, not benefit from experiences on the project that can be used to improve moving forward. As the PMI puts it, "Failure to conduct thorough project closeout could potentially (a) put the organization at a considerable amount of risk, (b) prevent the organization from realizing the anticipated benefits from the deliverables of the project, (c) result in significant losses to the organization, and (d) undermine the project manager and project management team's credibility."
I believe that the closure phase is becoming increasingly even more important.
Historically, the closeout phase was the time where all aspects of the project would be agreed to be concluded to the satisfaction of your client or senior management. After closeout, key team members would leave so this would be a valuable last chance to learn together. The project manager’s role in this closure phase was to ensure that all facets of the project were properly concluded. Also, at the end of a project team members can sometimes lose focus and discipline (after all you've delivered the project) so it would the PM's job to help the team retain its attention for these final (important) activities.
In reality, all too often, the closure phase is considered a tick box exercise which is undertaken at some point long after the cut and thrust of project delivery has become a distant memory. That needs to change. Not just because it is a sensible stage of any project delivery but because I believe that the project timeline is changing – it is getting longer.
In a recent blog I talked about the importance of ‘Marrying IT Strategy and Projects’, we focused on the need to define outcomes and how a business case helps with this alignment. In that article we highlighted the definition of a business case as “justification for pursuing a course of action in an organizational context to meet stated organizational objectives or goals.” the words to focus on, are organisational objectives and goals. In other words, the principal reason for any project is that they help to meet the goals of the organisation, seems sensible enough, doesn’t it?
There is a challenge here though and it is all down to when project benefits are typically realised. Moreover, this tends to be long term. Consider an ERP implementation that is undertaken to improve efficiency and information availability, at what point are these benefits realised and at what point can they realistically be measured? The answer often is at 'some point' long after the project is ‘officially’ considered complete. It is only when new technology becomes embedded (which takes time) that the true benefits are seen within the organisation.
I believe therefore that, as strategy and project delivery become more aligned, the focus on benefits and their realisation (both short and long-term) will remain with the project team. The natural consequence of this is an extending of the delivery and/or closure phases. Project teams will own the benefits realisation and, as this will not become clear until 'some point' after implementation, the time that a project team needs to be available to work on a project is stretched along the timeline, adding further pressure to over utilised resources.
This is where Project Management as a Service comes in.
Transition into service is the part of the process where project managers report the greatest 'value leak' - to return to that football analogy from earlier it's like setting up the perfect goal only for the striker to squander the chance by blasting the ball over the bar! You probably have tight governance throughout the project life cycle, but how well you finish your project? It is key to leveraging maximum business value! How well defined are your processes that move your project into BAU? Is your service delivery capability geared up to maintain the project deliverables? Through Service Delivery Assessments we are often surprised at how otherwise clued up clients are leaving this to chance - even the most capable project teams often find there is huge value in 'buying in' delivery management services.
The solution to literally every issue we have discussed here (and many others that we didn't have space to cover) can be found when you work with the right PMaaS partner. As project timelines become more stretched it is increasingly important that project teams find innovative ways to resource them. As projects become more complex and business case aligned, and as realisation of benefits becomes more of a future event it has never been more important to define endpoints and measure success in terms of actual business gains - no matter how long after delivery they come to fruition.
Aziz, E. E. (2015). Project closing: the small process group with big impact.
Waterfall. What Is It, When Should You Use It?
1970 was quite a year for firsts! The first jumbo jet to land in Britain, a Boeing 747, touched down at Heathrow Airport; the first Glastonbury Festival was held, as the Worthy Farm Pop Festival; eighteen years olds were allowed to vote in a UK General Election for the first time; and in a paper by Dr. Winston W. Royce, the phases of the Waterfall methodology were first formally published (although, like Glastonbury, it wasn't immediately called that!)
The Waterfall method has been the go-to approach for Project Teams throughout much of my career, but I am noticing that it is becoming less popular as teams opt for more agile models. It is, however, still relevant today and can bring you massive benefits.
Here’s what I wrote in my flyover post ...
Waterfall is among the "old faithful" methodologies, one that many Project Managers consider their default setting.
When Is It Most Effective? When your larger IT Project has crucial milestones and deadlines, and when tasks can be clearly defined & sequenced. Also useful for tame projects, i.e. projects that you've done before and expect to proceed in exactly the same way with no surprises.
A good non-IT comparison is house building! So, in house building, you to need to dig foundations and build walls before you “top off “. Also, you design the whole thing – from end to end - it would be a disaster if you didn’t know whether you were building a bungalow, house or an apartment.
What Is It? As the name suggests, Waterfall is a sequential methodology which progresses your project in a single downward direction that typically delivers at the end. Documentation is key to Waterfall success, the measure of this is often when a project manager leaves - how easily can his successor pick up the project? It is a fairly inflexible process but perfect, if your project doesn't need to be agile (if it does, I can think of at least one better alternative).
I asked some IT Project contacts for their thoughts ...
What Advocates of Waterfall say
ORGANISATION - It forces you to be organised. "Waterfall methodology forces discipline on you and your project. If you struggle with structure, waterfall is the best model for nagging you into line."
GREAT FOR LESS STABLE TEAMS - It's great for more fluid teams. "Our projects team members come and go, the structured documenting that waterfall requires is ideal for incoming staff so that they can hit the ground running.
EASIER TO FOLLOW - Following on from the above, everyone knows just where in the life cycle of the project they are - at every stage. This allows project managers to be more organised and to keep the process flowing.
MILES AHEAD FOR MILESTONES - Perfect for milestone and deadline driven projects. The linear structure of waterfall lends itself to projects and teams that are suited to ‘milestone led working’ due to the ease with which "a timeline for the whole project can be drawn and easily marked into stages. This adds clarity to the project that makes communication and understanding across the team fairly easy."
EARLY CHANGES - Great for projects which benefit from (or have a need for) design alterations early on in the process. Changes can easily be accommodated early on in the lifecycle (although, admittedly, it gets harder further on).
BETTER QUALITY OUTCOMES - Waterfall often delivers a better end product. Each stage of the waterfall process is effectively spent debugging, you don't move on until the stage you are working on is acceptable so if you follow that logically to the end conclusion you should finish up with a product that is perfect.
LESS NEED FOR MICROMANAGEMENT - The 'rules' of Waterfall sort of look after a lot of your management needs - you don't move on until you've completed each step. "It actually saves me time managing in the project because the rules are well established and understood which allows me time to work on the project, taking a helicopter view of the project rather than getting bogged down in little details.”
What Waterfall's Detractors Say
CHANGES ARE DIFFICULT – Although it may accommodate early stage changes, because Waterfall is a set of sequential steps, once you have moved on, alterations to previous elements of the project are harder than with more agile solutions. Not impossible! We joke that one PM friend is so adept at swimming back upstream using waterfall he must have been a salmon in a previous life. The truth is that he has adapted Waterfall so it is almost a hybrid of Waterfall and Agile and the key is an awareness of how a retrospective change to a previous stage will affect successive stages and making a judgement call based upon that. Also, any changes that are made have to meticulously documented.
TRADITIONALLY, LATE TESTING MEANS ERRORS ARE FOUND LESS QUICKLY - Some Waterfall users, following a traditional template, say that late testing of a project means that problems are found later and are therefore harder to put right. The workaround for this, as hinted earlier, is to test at every stage before moving on.
LESS TRANSPARENT FOR STAKEHOLDERS - Waterfall is a bit of a closed shop! Waterfall is great for keeping your team up to date but those using it tend not to share progress with clients and stakeholders. One PM put it like this, "If you're building a house, when does it start to look like the house your client is imagining? Not when you dig the foundations, not when you lay the first bricks, it isn't until the late stages, when the roof goes on or you hang the doors and windows that it finally becomes a house. It's the same with Waterfall IT Projects, there's no point sharing meaningful information about your project until close to delivery, to do otherwise is like taking a builder showing their client the holes they've dug for the foundations and asking, 'What do you think of your house?' - waste of time."
The Waterfall methodology has attracted lovers and haters since day one. The fact that almost 50 years on we are still using it and other new methodologies have emerged over time to address its flaws suggests that it as relevant today as it ever was. Waterfall can be the perfect Project Management framework, it lends itself well to hybrid approaches and if you have a smaller team or your project is not prone to scope change it is probably the most effective process.
Like with actual waterfalls, if you get it right you have a lovely water feature that Ground Force’s Charlie Dimmock would have been proud off; get it wrong and you can have a messy flood on your hands. The more competent you are, the better the result you’ll get! As always, the Project Management Service market is geared to help with any capability gaps that you have.
Find out more about Project Management as a Service from Stoneseed
He called the garage that he used to take the car to for MOTs and servicing and asked if they could help. As it was an electrical issue they advised they would have to call in an auto-electrics expert at a cost of £50 then £50 per hour plus parts and labour from the garage - and they couldn't guarantee that ‘Mr £50 call out’ would be able to diagnose the problem.
My friend then tried the main dealer. They said that they WOULD be able to diagnose the issue, in fact just from the call they were certain that they knew what the problem was. They wouldn't have to call in a guy as all the diagnostic tools were on site, so it would be parts and labour. The estimate was £500.
In the meantime, my friend had been given the number of a local 4x4 specialist, in fact, these guys were specialists on this brand, both having trained at the main dealer before setting up on their own. They also were certain that they could diagnose the issue and while they were happy for my friend to bring his vehicle in, there was something that they wanted him to try.
"Put the car in reverse and drive for as long as it takes for the 'R' to register on the dashboard. Then, put the car into first and drive, changing through the gears as each registers on the dash and when you get to sixth gear, pull over, turn off the ignition get out of the car and turn on the alarm. Then unlock the car and call us back to tell us what happens".
Well, my friend thought these guys were having a laugh but did as they said. Guess what? Within ten minutes the reverse light was working and the gears registering as they should. He called the garage and was told that this is probably what the main dealer would have tried first (and charged £500 for). It was the car’s equivalent of a hard reboot.
The relevance of this story to IT Project Management is that sometimes the fix you need is a really quick one, sometimes you don't need to embark on an expensive voyage of discovery, sometimes you just need someone who won't rip you off to point you in the right direction.
The above story came to mind when I was asked to help with an IT Project recently and having taken a look I turned down the work. The reason was that this project, that the in-house team had been struggling with, wasn't a project at all - it was a software purchase. I'm not even joking, the thing that they had been trying to build was available as a ready to run a bit of accounting software.
They had received quotes from a software firm to build the desired package from scratch.
They had also sourced a proposal from a project management services firm complete with costings for 'as a Service' resources that would complement the in-house team's efforts to deliver the existing project.
Then there was me, suggesting that they do the equivalent of sticking their project in reverse, drive up the street and flick on the alarm.
One of the common characteristics of firms with high rates of project failure is that they have too many projects on the go at once. There's nothing wrong, in principle, with having a HUGE portfolio of projects if you have the resources to deliver or you have a great Project Delivery and Project Management as a Service partner - but I urge you to do the "Is this even a Project" test.
Over my career, I have found that the word project is as misused and misunderstood as the word "Ironic" is in the Alanis Morissette song of the same name. If it rains on your wedding day, that’s a meteorological coincidence, not ironic. If you win the lottery and drop dead the next that's just remarkable good luck followed by bad luck. If you meet the man of your dreams and then meet his beautiful wife, that's not irony, that's just sickening. Maybe the irony is that the song called “Ironic” contains no irony.
Anyway, I digress.
The thing is, that a lot of what gets called an IT Project really isn't a project at all; but because it has been labelled thus and allocated to the IT Project team it will devour resources, water down the potency and distract the attention of the Project Management Office and delay actual IT projects within the wider portfolio that were destined to deliver real business value.
Now that, Alanis, IS ironic. Probably.
I used to think that this was mainly an issue in the public sector where pressure on budgets may not be as much a matter of life and death but recently I am increasingly seeing ‘non-projects’ draining the resources of private sector organisations as well.
The PMI’s Project Management Body of Knowledge defines a project as "a temporary endeavour undertaken to create a unique product, service or result. Furthermore, it is "temporary in that it has a defined beginning and end in time, and therefore defined scope and resources" and "unique in that it is not a routine operation, but a specific set of operations designed to accomplish a singular goal".
That's pretty neat definition.
In his article for CIO.com, Antonio Nieto-Rodriguez writes "Set some clear and objective criteria of what is a project (changing-the-business), and what should be considered as day-to-day activities (or what I call, running-the-business)."
I would also consider the size of the project's budget, impact on the business (how many departments will be affected or benefit from the 'project', the duration allocated and expected delivery schedule (is anything less than six months really a project?) and how aligned with the strategic goals of the business the project is.
The project that I recommended was instead a software purchase had been allocated a three-month lifecycle, a few thousand pounds budget and it would impact one (maybe two) business units. They'd taken it on because it seemed like an easy deliver. Get in, get the gold, get the credit for another project delivered. In reality, it was over time, over budget and all the while diverting resources away from the rest of the project portfolio and projects that would affect real business change.
To conclude, budgets are not blank cheques these days. The pressure on IT Projects to deliver return on investment is greater than ever and failure rates are as high as they have always been. It's time for us all to act more selfishly and for the good of strategic business, delivery focus on the projects that matter. If you struggle to identify the difference between these sometimes an independent pair of eyes, taking a fresh look can see things that you can’t – and it’s OK to ask for that help!
The deliverables of 'non-projects' can still be attained but with simple purchases or simply, as Antonio Nieto-Rodriguez says, running the business.
So, Let's stick to only calling them projects when they are projects. Otherwise, it's like ten thousand spoons when all you need is a knife … isn't that right Alanis?
It's actually (paradoxically) both easy and hard to nail this. Some project teams struggle but, like with most things, you just need someone to show you how and from then on, it's easy! I believe with a little effort you can ensure that EVERYONE involved with the project knows what to expect and when.
Five shortcuts to managing stakeholder expectation
1 - Plan the journey together before fixing on an eta
One of the first questions a lot of clients and stakeholders ask when you meet to discuss a project is "What will be the delivery date?"
Would you plan any other journey like this? I mean if we decided to travel to Buenos Aires - how accurately could you predict an ETA? You wouldn't take a guess before breaking the journey down into its different parts, would you? You'd have to work out which airport to fly from; what time the departures are and how long the flights are; how to get to the airport and how you get from the airport to your destination at the other end.
Too many IT Project delivery dates are agreed without due attention to the tasks and milestones along the way. Like our journey to Argentina, break down the project into chunks and agree on scope and delivery timetables based on proper measured thought.
Funny story, back in the day some friends of the family who are London based Arsenal football fans, set off for an FA Cup tie in Wrexham. It was the days before Satnavs and the task of planning the route was left to an uncle. It was a good hour and a half into the journey before they realised that the route he had planned was taking them to Wroxham in Norfolk rather than Wrexham in North Wales. The moral is that proper journey planning may take a little time up front but it will pay back later with accurate timescales and clearly defined and agreed expectations.
2 - Your plan - KISS
KISS - Keep it Simple (for) Stakeholders
What this means, in essence, is don't overcomplicate documentation and plans. I recall a project where the team detailed each task within the project, each milestone, in microscopic detail. The business stakeholders didn't care about any of this, they just wanted to know when the project's deliverables would be transitioned into service and when they would start seeing a return on investment (ROI). This vital information got lost in the noise and the stakeholders created an unrealistic expectation that was different to what the project team had been trying to communicate.
The project delivered in line the project team's expectations, on time, on budget and delivering the business change promised but it was not within the false expectations of the stakeholders. This resulted in the project team having to engage in some pretty awkward conversations with disgruntled stakeholder clients who had misunderstood the over complex planning documents. You know the adage, "The customer is always right"? Having to tell them that they're not is never easy – especially when it’s kind of your fault they got the wrong end of the stick. K-I-S-S!
Avoid this by playing to your audience, deliver it in their language. If, as in this case, your stakeholders are business minded, deliver your plan to show you clearly understand business need, expectations and requirements. Ensure that they are documented in a way that cannot be misunderstood in your scope statement. Less is more!
3 - Keep it REAL
Realistic Expectations Allowing (for) Lag
When planning, you work backwards from project delivery and work out timings for tasks. You add these timings together and that gives you your project lifecycle. OK, that's a little simplified but that's pretty much it - but what happens to your project and by default your client or stakeholder expectations if something goes wrong?
The most successful project leaders and CIOs allow time in their project timelines for 'eventualities' and conflicts.
Say the project's task add together to five months, rather than agree five months with your stakeholder and communicate that to your team push for six or seven months. If the team delivers the project in five then they feel like rock stars, their morale is lifted, and you get to carry that confidence onto your next project and the best bit - your stakeholders think you're the best because you delivered with a month or two to spare.
Keeping it REAL requires being mindful of business needs and pressures. I mean, don't take the mickey, if the project needs to deliver to market in five months to compete with a rival, then it’s in your interests to bust a gut to achieve that.
BUT if you can buy some time it's a very wise investment.
4 -Update, update, update
The most important part of setting and achieving milestones isn't that you've set and achieved milestones. It's that you have communicated them with your client.
Many project teams see milestones as internal progress markers but actually, they are crucial for managing client and stakeholder expectations too.
If you hit the first few milestones late but advise your client, you can either assure them of steps that you'll be taking to catch up or begin to prepare them for later than planned delivery.
I was on a train recently that was a minute late leaving the first station, two minutes at the second and so on. The Train Manager announced each delay with an apology but what he failed to communicate was the impact on our final arrival. A near riot was about to ensue among passengers as they speculated and advised those collecting them from the station that they may be late. Then the guy explained over the loudspeakers that despite delays along the route we would arrive at our destination on time (the train companies are very good at point 3 and pad their journey times to avoid fines!!).
A final word on the bit about updating. Be honest when things go wrong - when it comes to managing expectations nothing beats the truth and the goodwill that this honesty generates (almost) always buys you some understanding should you hit further issues along the way.
5 - Pick your best team
It's amazing how far a client's or stakeholder's confidence in your team goes towards how they create their expectation of your capability to deliver. Breaking down tasks and knowing who, on your team, will perform them best and knowing who will work well together when required is a real skill; the better you become at it - the better your team will become at delivering successful, high quality, business case led projects.
If you identify a capability gap the Project Management as a Services market has an abundance of resources ready to plug straight in - so don't feel that you have to chance it. Allow me one last football analogy? It's like the difference between when a football manager fields a weakened team in a cup tie and they get hammered and knocked out of the competition, and when a manager fields his full strength team and they scrape a win. The benefit of the doubt from the fans is far more likely to be forthcoming following the latter scenario - and so it is with stakeholders of IT Projects. Always field your best team (and that includes drafting in external resources if you need to).
In conclusion, managing setting and managing expectations can be one of the hardest things to get right in IT Project Management but it’s also one of the most rewarding. Making sure that EVERYONE is always on the same page should be a priority for us all!
If you have any thoughts, ideas to add or you need some help with this in your projects, I EXPECT that you know how to get in touch.
Find out more about Project Management as a Service]]>
Have you seen the video of 7-year-old runner Rudolph 'Blaze' Ingram who sprinted 100 metres in just 13.48 seconds?
It's fascinating to watch this young Florida athlete speed out of the blocks; and after clocking up thousands and thousands of Instagram views, as I write this, he has made the national television news here in the UK. To put this all in context, 9.58 seconds is the men's world record, set by Usain Bolt in 2009, and the women's record, set by Florence Griffith-Joyner in 1998 is 10.49 seconds.
Wow!! Those of you who know me will testify that I too, cut rather an athletic figure and for us IT Project Managers the similarities don't end there.
Reading more about this remarkable young man and listening to former athletes analyse the video it struck me how carefully planned every metre, almost every centimetre, of a 100-metre sprint is at the elite level.
When launching an IT Project, leaders and managers and their teams need to be equally quick out of the blocks and we too have to be meticulous and disciplined in our planning and execution.
The start-up phase of an IT Project is like a 100m sprint, over quicker than you think and what you get out of it at the finish tape is entirely dependent on what you do every step of the way. The 100m sprint is a pretty good metaphor for the first 100 days of an IT Project, especially for a new project leader within an organisation.
Let's run through it together.
So, the starter's pistol fires and you are off ...
0-25 Metres - Assess!
This is where you prepare and suss out your surroundings. By the 25th day, you should have completed your preparation and assessment phase. You should be engaged with key stakeholders, staff and organisational leaders. You should have learned what requirements and pain points need to be addressed first. Perception is reality and these early stages really can establish how you are perceived within the wider organisation - this will pay you back later if you get it right! When you establish strong relationships across the organisation, with influential executives who understand the value of the PMO, when you establish good reporting structures with these individuals, you will find that when you need support further down the track - it will be much more forthcoming.
By this stage, you should have assessed your resources and established what gaps you have and how you are going to fill them. Do you have the staff in-house to deliver the project, or will you parachute in resources from the Project Management as a Service sector?
I also like to identify a few key challenges that can be tackled and put to bed during the 100m sprint, your capability to deliver visible results early on can create a powerful perception within your organisation that often means you get the benefit of any stakeholder doubt later in the project...
20-50 Metres - Plan!
Around 20 days in, and still during this assessment phase your thinking needs to be split between the assessment phase and the start of your planning stage. The planning part of the project can last until about your 50th day - the halfway stage of your initial sprint!
Plans should be flexible and clear, simple but well defined, ideally, you are also be preparing an action plan for your second 100-metre sprint at this stage too.
Canvass the opinion of key stakeholders around this time also, share your draft plans with them and based on their reaction and enthusiasm make appropriate alterations.
At this stage, really think about the resources that you'll need to execute your plan. Recruiting from within and explore Project Management as a Service resources you may require to help deliver your project.
40-90 Metres - Action
Again, this stage overlaps the last and I cannot stress the importance of starting to act as soon as possible - if you feel confident to start executing sooner than this, don't hesitate! The greatest PMOs start implementing plans that they can alongside their long-term planning phase. I reckon it's not unreasonable to expect to complete one or two major milestones during this time - be bold!
Shout about ANY successful early result, your credibility increases with every early win, so don't be afraid to blow your trumpet! These results broker engagement across IT and business management stakeholders.
40-100 Metres - Measure
Measurement of the results of your actions should actually begin at the same time you start taking the actions themselves. The more you measure, the more you anticipate and the more you anticipate the more you succeed.
The final third of your initial 100m sprint should be focussed on creating firm foundations for the future and a launch pad for the next phase for your maturing PMO. This current project will fit within your wider project portfolio management (PPM) ambitions - now is a good time to measure that too!
The confidence and credibility gained throughout this first stage really pushes you on, not just in the physical sense either.
In one social media post, the star of our story, young Rudolph is pictured with a serious look on his face as he gets sets for a race and the caption reads 'My Father Told Me That You Win Mentally Before You Win Physically, I'm #1 Before The Race Start.'
I've seen projects succeed and fail based on the quality of mental preparation - teams that visualise success usually succeed and teams who visualise lots of problems encounter lots of problems. It's easier to achieve success that you've planned for and the earlier that success comes (remember those early milestones) the sooner they can have an impact on morale.
Of course, at this stage, the work of the 100m sprinter is done. For you, the finish tape of this initial sprint is just the beginning, but it will probably feel like less than 14 seconds have passed. Time flies!
Now, get your breath and run on!
Find out more about Project Management as a Service