Even as I wrote the sentence above it felt such an obvious thing to say but, time and again, I am seeing the PMOs operate in harmony with the first half of the statement and not the second. In other words, the leaders of the PMO have identified that organisational need must be prioritised to realise maximum business benefit but the way they go about it is at odds with their organisation's culture, either that or they have misunderstood the needs, or they are just speaking a different language.
Mbula Schoen, Senior Research Analyst at Gartner, says, "PPM leaders should engage the business and key PMO stakeholders to identify the critical needs and issues of the organization, and then design a PMO that will best meet those needs and resolve those issues."
Most organisations would be in broad agreement with all of this, business stakeholders and project teams alike. After all, what is the point of any part of a business if it is not set up to deliver business goals and function in accordance with the culture and the modus operandi of the business it is serving. Often though, this is not the case and projects that should otherwise succeed are failing through lack of alignment of working ideology.
The issue can be caused by a number of simple things. Projects teams can, paradoxically, be too close and too far removed from their parent businesses to identify cohesion between each other’s working ethos, sometimes project teams are just too 'hard-wired' to adapt their way of working to match their wider organisation and at other times they have become so closely aligned that they forget standard project management best practice.
There are occasions where the maturity of the sponsor organisation has been misjudged. For instance, some businesses need more than just a delivery into service function, they may need business case analysis, perhaps risk assessment, they may need business alignment to be properly measured and justified or they may need greater compliance. If the organisation's PMO is set up to create structures that deliver project after project in roughly the same way but the client needs more then there will be a growing disconnect between the two over time.
Often though, it’s no one's fault it’s just that, well, things change!
Gartner's Mbula Schoen has identified four types of PMO that are commonly found. She categorises them as "The Activist PMO", "The Delivery PMO", "The Compliance PMO" and "The Centralised PMO". What is interesting is that, even with clear definitions alongside each one, it can be hard to identify which approach best suits your current needs; let alone in the future. Given the speed of change within business landscapes, what works now may not be suitable after disruption in your market, or a takeover. While Miss Schoen is right to identify the four most common types, as I think she points out herself, there is no "one size fits all" PMO and flexibility has, in my view, never been more important.
The Project Management as a Service sector is perfectly geared up to help with all of this. If your project management services partner has done the appropriate spade work, they will be able to recommend solutions based on your maturity and unique business needs and if they have really got to know your business and its requirements they will also be in a position to help forecast and satisfy changing demands.
As previously mentioned, project teams can get too close to and be too distant from their organisation, so often it is just really useful to have an independent pair of eyes look objectively at the needs across your portfolio.
Last year, a project manager friend had to carry out a "Gedanken" or thought experiment for his employer when the business was considering a takeover of a rival firm. The brief was to assess the potential needs of the newly merged business and hypothesize about the type of PMO that would be needed. He described the experience as being like "trying to get your head around Schrödinger's cat"! Even with pretty robust forecasts, a good idea of how the new business would look and using the same Gartner PMO models that we've discussed here; it was really difficult to map with any degree of certainty the exact match between PMO type and business need.
Try it yourself! Spend a minute visualising where your business is at right now, think of your current PMO, if you have one, or imagine what type of PMO would deliver the most value to your business right now. Take a look at the four types identified by Gartner's Mbula Schoen below and try to throw forward six months, a year, two years ... which of these will deliver most value then?
The Activist PMO? - "Popular in enterprises with distributed, business-centric project ownership, the activist PMO takes a broad view and enabling approach as opposed to a controlling approach. Typically, it has a view of incoming project demand, and supports decision makers by analysing business cases for alignment and risk; that is, the PMO vets business cases and project proposals. This broad view provides a project portfolio dashboard of the status of all projects that it maintains, and oversight so that when projects in the dashboard go “red” - it might suggest or solicit remedies."
The Delivery PMO? - "Also known as the project delivery PMO — is perhaps the most commonly found style. Gartner estimates that at least 40% of PMOs are mainly delivery PMOs charged with planning and controlling the tactical execution of projects to business expectations. Project managers are encouraged to manage their projects, proactively make decisions and escalate problems. The goal is also to build repeatable processes and techniques that will work to build a culture focused on results.
The Compliance PMO? - "Often the most suitable style for organizations where documentation, processes, procedures and methodologies are lacking or inconsistent. In this scenario, the compliance PMO tends to be tasked with establishing standard practices for measuring project performance and the development of a capability for understanding the status of key initiatives."
The Centralized PMO? - "When PPM maturity levels are low, organizations depend on the skills and abilities of key performers to get work done. At higher levels, efficiency is key, and management seeks to reduce this dependency and establish reliable processes for project tracking and reporting. A centralized PMO is therefore formed as a place where new hires can be quickly brought up to speed on how best to get project work done in the organization. In the centralized PMO, representatives from the various project support organizations get together to share their practices in a best-practices council."
Has your mind turned to blancmange yet?
To conclude. While it is true that you can identify which types of PMO deliver the most value NOW, based on past data, it is a lot harder to predict how to align a visualised future PMO with the needs of your future business. My friend said it was like "minding mice at a crossroads!"
Where's that Schrödinger's cat when you need it!!
The most sensible solution appears to be the one that will give you the most flexibility. Once he'd got over his cat and mouse issues my friend's conclusion to his boss was to recommend use the Project Management as a Service market to give the business access to resources and ways of working as and when they were needed - "why build when you can rent" was his closing statement to the board. The takeover is yet to happen, which is why I can't name the business (or my friend) but if in the near future you hear of a large corporate takeover and you marvel at the apparent ease of IT integration and the versatility of the IT project management, you'll know that you heard it here first.
The same flexibility could be the key to your PMO delivering more business value to you too, now and in the future.
Find out more about Project Management as a Service
Last Summer I read a blog post by Moira Alexander, one of CIO.com's most engaging contributors on Project management issues, about the importance and value of a strategic Project Management Office (PMO). I love Moira's writing because she is so passionate about the journey, we are all on and her thoughts often chime with my own.
Moira wrote, "Strategic-level (PMOs), also known as enterprise project management offices, are essential in developing, maintaining and communicating effective project, program and portfolio practices. Having a solid company-wide strategic plan provides the blueprint that all PMO initiatives should align with and be measured against. Unfortunately, only 41 per cent of strategic PMOs have a high level of alignment with their organization's strategy."
Considering the increased emphasis on the need for IT Projects to deliver greater business value and the continuing high rates of project failure, it struck me as odd that less than half of organisations had demonstrably aligned project and business outcomes. As I say, and my colleagues will confirm, this is a well-banged drum of mine, so I decided to ask around to see how true that 41% figure quoted was.
It turns out it's very true!
A quick straw poll of ten industry colleagues revealed five had experienced disconnect between IT Project and overall business strategy in recent times.
I would urge you to read Moira's article as I think, as usual, she hits many a nail on the head!
Among Moira's tips, establishing a clear understanding of the company’s vision and mission may be the most obvious but also the most important. As she writes, "Without a clear understanding of the company's vision, mission and goals, it is virtually impossible to establish a successful PMO plan. To get a complete picture of the company’s overall strategic vision and mission, PMO leaders must be directly involved in executive planning sessions at a strategic level. This is the only way a PMO can truly be effective in its approach and endeavours."
It's not a new thing. As far back as 2005, a study conducted by Dr Brian Hobbs with over 200 companies in the U.S. and Canada, found 39% of organisations had questioned the business value brought by their PMO. "For the PMO to fill this new role," wrote the Project Management Institute (PMI), "Considerable structural changes must take place in the organization. The PMO has to evolve from an operational structure of projects into a portfolio management structure which is focused on the results and benefits generated by the project execution".
So, over a decade later why hasn't much changed?
Many report that it's a staffing issue.
As organisations increasingly place a greater focus on the business value of a Project Management Office, they are naturally looking for talent with relevant experience. IT Recruitment Specialist, Access Talent (our sister company) is reporting that IT job specifications are evolving to include relevant skills, like requiring candidates to have a track record in business case focussed project implementation, for instance.
The problem is that the IT Project Management Recruitment sector was already seeing a steady rise in demand for PMO Specialists, fuelled by an influx of projects related to the recent changes to GDPR, in a business world geared towards greater data compliance the PMO has stepped up to be a crucial safeguarding resource. Most businesses have elevated their view of the Project Management Office beyond that of a cost centre and PMOs are expected to create business value. With the increased ROI expectation from project delivery, comes greater demand for the appropriate talent to make that happen and the real possibility of a skills shortage in 2019.
Project Management as a Service (PMaaS) can help here, with resources to fill any skills gap that may be threatening ROI.
Anecdotally, project teams also tell me that they are snowed under, as one Project Manager put it, "We're too busy spinning all the other plates" to pay too much attention to business strategy alignment. I'm not sure how much longer we'll able to use our workload as a justification for taking our eye off the company objectives, it feels like the transport manager saying his drivers are too busy delivering to pay attention to where they are delivering too. It cuts both ways though, while project teams are often too busy to align their work with business case I also know executive stakeholders who are too busy running the business to have a firm handle on how IT Projects contribute to it. This is a communication gap that needs bridging.
The PMI's learning library suggests five pointers that would assist with this goal communication issue:
1 - Speak in proper language when communicating with business executives;
2 - Clarify projects' benefits to all stakeholders;
3 - Build a project plan that covers strategic risks;
4 - Guarantee the best use of company's resources;
5 - Understand how projects bring value to their company.
Again, it seems too simple but sometimes you just need the obvious spelling out.
I've seen end-to-end Project Management Office, sourced as a Service, deliver all of the above. The solution can be 'bought in' if your current structure is not delivering IT Projects married to business case.
As always, in a blog, we only have time to skim the surface but if your projects are not delivering in line with business need then, ultimately, you are wasting vital resources. It is crucial that your PMO has a strategic plan and always executes accordingly - successful implementation of the plan being the all-important bit in terms of delivering business value.
"Innovation results from creative ideas successfully implemented. Competitive advantage is as much about execution as it is about strategy." This quote, from as far back as 2002, is as true today as it was then. In 'Winning Through Innovation: A Practical Guide to Leading Organizational Change and Renewal', Michael L. Tushman spelt out the challenges and many of them still exist today 17 years later! The only difference now is that the pendulum of responsibility has swung our way, project management teams have to deliver in a way is consistent with business strategy and if they can't businesses may have to look for a project team that can.
Find out more about Stoneseed's PMO services
'Winning Through Innovation: A Practical Guide to Leading Organizational Change and Renewal'(Tushman, 2002, p. 19)
All that pitching, planning and preparation has led to this point! You are ready and raring to go and as you line up the road ahead, your attention will have turned to how you document and communicate within your project. At this point, you are probably thinking about initiating a RAID log. You can knock one up in Excel, one of the most effective tools you can easily create for your project ... until now ...
RAID logs are pretty cool!! RAID is mentioned in all project methodologies, I can't think of a Project Manager who doesn't use one.
However, I also can't think of a PM who doesn't also use other documents alongside it. Simplicity is one of the advantages of the RAID log but it is also one of its drawbacks. Risk, Actions, Issues and Dependencies are neatly covered by the RAID log, on one single document but often project teams find that they need other documents that review and record change, decisions, lessons learnt etc.
Your problems can really start when something happens in your project that doesn't fit into one of these tabs - what then? This is where PMs either turn to a separate document or, worse still, try to keep all this information in their head. The trouble is that with everything going on across your portfolio there's likely to be a lot going through that head of yours and, being human, PM's forget! Truth is, what's not recorded well cannot be monitored, reviewed and acted upon.
Even when things are well recorded on separate documents, maintenance of these many documents can be confusing for clients and stakeholders and it is often in this confusion that mistakes can occur that leak value.
So often, a RAID log doesn't always give a full and accurate picture of the status of the IT Project.
Many Project Leaders and CIOs said that they needed something more RADICAL.
Appropriately, together with my colleagues at Stoneseed (the IT Project Management, Technical and Service Delivery specialists), we streamlined the management of project related documentation into one RADICAL log.
Let's break it down;
Stoneseed's RADICAL log covers;
R - Risks
A - Actions
D - Dependencies
I - Issues
C - Changes
A - Assumptions/Decisions
L - Lesson Learnt
The advantages are many, but chiefly;
1 - Having one document works better for the client ...
... and it works better for you. Rather than updating various documents, the RADICAL log gives you real-time transparency. To have all project related info in the same place, a holistic overview provides you with the opportunity for a regular look at everything! It is a living and breathing single document rather than a hunt for information through loads of documents
2 - Using one document means that events are MORE likely to actually get recorded
On this, a Project Manager friend compares RAID logs to when you put the bins out. He says. "We have different bins for recycling paper, card, plastic, glass, garden waste, etc. The other night I had some rubbish that I couldn't fit into one of these categories! I agonised for a few minutes and then reluctantly threw it into the general bin. In many projects, this has been what has happened to, for example, a valuable lesson that has been learnt. Where do you document that? It's not a risk or an action, neither is it a dependency nor an issue and yet paradoxically, a lesson learnt could be all of these! So, traditionally, lessons have ended up in the RAID log equivalent of our green bin and have been missed by other project team members."
3 - You declutter each category
I was asked to help a project team with a floundering project last year. The first thing we did was look through the recorded documentation for clues - from project charter to the delivery into service plan, everything seemed meticulously prepared. Then, we looked at the RAID log and oh my days!! Each category was pages and pages long giving a very unclear instant picture of the health of the project.
At RAID review meetings the team ran through the whole document starting with the risk section which, from memory, was about seven pages. Now, many of the entries were not really risks - more assumptions or concerns that fell into a bit of a RAID grey area. However, because of the RAID methodology, there was nowhere else for the team to register these "grey area concerns" so they had been lumped into 'risks'. The result was that when the team met on a weekly basis, they only had time to chat through a couple of pages of the whole RAID log (all risk - i.e., stuff that might never happen) and there was insufficient time for proper consideration of actions, issues and dependencies - the real day to day life of the project.
Of course, better prioritisation would have helped. Even using a RAID log there were things this team could have done better. Low-risk projects require that the team spend less time discussing risks versus, for instance, issues, there was a failure in the implementation of this teams RAID log. That said, filtering log entries further using the RADICAL approach means that only bona fide risks make it onto that part of the spreadsheet because there is place elsewhere for grey area concerns.
4 – RADICAL improves response quality
The items in each of category of a RAID log necessitate different follow-up methods. The difference between an "issue" and a "risk", for example. The former is a cast iron problem - it's something that needs action, perhaps changes and there will be lessons that can and should be digested. A risk, conversely, is a potential problem, effectively a problem that hasn't happened yet - it still needs attention, solutions that may never be used must be brainstormed but in many cases, action is not required. On a standard RAID log the results of these brainstorms can get lost at this point - where do you log decisions for future reference if the risk becomes a reality? The RADICAL log provides a natural place to register these decisions.
5 – RADICAL makes you think about the project as a whole.
The RAID log is a brilliant tool and it really focusses your mind on the things that you have entered into those four categories. This can be a problem too. If you were told to notice how many vans, buses, cars and lorries you saw on your commute into work, every time you saw a vehicle from this category your subconscious mind would notice. You may arrive at work having not noticed all the motorbikes, milk floats and tractors you passed.
Much of your project brilliance comes from when your primary attention is focussed elsewhere, that is to say, that your eureka moments tend to come from your subconscious mind as opposed to when you go looking for them. When you limit your main project log to the four categories of a RAID log (and jot down other project events in separate documents) you train that part of your brain to limit awareness and thinking to Risk, Actions, Issues and Dependencies.
Using a RADICAL log extends your project awareness and encompasses a more holistic set of performance criteria.
Having one document, that is living and breathing, means you are always working on it and are, therefore, always aware of what is going on - everywhere!!
In conclusion, it is appropriate that this new approach is called "RADICAL" - project teams using it for the first time say this is exactly how the results feel. It's exciting! To return to my opening sentence, where I invited you to imagine the implementation phase of an IT Project, exciting is exactly how it should feel. Right?
Did you ever see Life of Brian?
One of the characters Reg, played by John Cleese, asks "What have the Romans ever done for us?"
One by one, other characters pipe up with loads of suggestions ... medicine ... roads ... public order ...
Eventually, Reg says, "All right, but apart from the sanitation, the medicine, education, wine, public order, irrigation, roads, a fresh water system, and public health, what have the Romans ever done for us?"
Today, ‘Reg’ was a company CEO who is currently streamlining the business to increase profitability. On a sheet of A4 paper headed "Cost Centres" was a list and the third item on that list were the words "Project Management Office".
Like most businesses, this firm established a project management office (PMO) to increase transparency and deliver greater efficiencies through their IT projects. This was pointed out but just like Reg in Python, it wasn't enough and the CEO asked, "Yeah, but what else?"
"Well, it aligned our IT and business strategies. Our IT is more business case focussed now," declared the Finance Director.
"... and culture. IT and the business are aligned culturally too." added the HR Director.
The Transport and Distribution Manager enthused, "The PMO got us to share resources better, techniques that delivered success with the finance department's new invoicing system got integrated into stock control and despatch"
"And purchasing too." added the Director of Procurement.
"All IT Projects are on time and within budget." said the CIO.
One by one, those in the meeting piled in with praise for the PMO. "IT is more user-friendly", "IT support is better", "Better access to good data from business strategic projects", "Better communication."
At this point I expected the CEO to echo Reg and ask, "Apart from business-aligned IT, shared methodologies, integrated systems, on time and in budget delivery, more user-friendly IT, better support, better access to data, better communication. What has the PMO done for us?"
He didn't. He just crossed "Project Management Office" off his list and moved on.
"Do we need a PMO?" is still a question I get asked a lot. Most businesses benefit from having one.
Most recently, this question came from a business with departments that functioned as silos, each operating different IT systems with limited (or no) connectivity between them. This was an example of when the answer is a glaringly obvious "yes - you need a PMO". It’s not always that easy to make the case for investment.
Even for this “obvious” candidate for a PMO, their next question was, "Can we afford to have a PMO?"
Resisting the temptation to glibly say, "Can you afford NOT to have a PMO," we explored the root of the question. Just like the CEO doing his Monty Python tribute act above, this business considered a Project Management Office as a cost. Some PMOs do generate income and as more businesses migrate to IT centred business models this will increasingly be the case. For now, though, the majority of PMOs will save money, drive efficiencies, improve communication, etc.
These things are always harder to show on a spreadsheet than revenue!
This firm runs IT projects with an increasingly significant cost attached to them and the impact of them is increasingly strategic from a business perspective. The bigger and more complex the projects you run are, the greater the return on your PMO investment will be. And yet, still, they questioned the financial logic. In the end, we came up with a solution via the Project Management as a Service route, through which individuals and teams or, in this case, end to end PMO can be accessed - as and when needed.
If you are currently considering any significant IT projects or changes to your strategy through IT then it is definitely worth considering a strategically aligned PMO. The PMI’s 2017 Pulse of the Profession report demonstrated that firms with a PMO aligned with their business strategy had 38% more projects meet intended goals and satisfy business case than those that did not. They also report 33% fewer failures. Even Python's Reg would find it hard to argue with those figures.
So to answer the opening question, "who needs a PMO?" Probably, you do and thanks to the PMaaS market, you don't have to add to your own headcount to get a fully functioning one!
This week, I suggested that a client gets a Project Management Office.
With their permission, I'll share the reasons behind the recommendation because they may resonate with you and where your business or project management operation is right now.
There’s no golden rule or measure that dictates when it's time to start a PMO. It's got nothing to do with the size of your business, the revenue it generates or even the complexity of projects. Often it is a range of (independently) insignificant signs that add up to suggest that a Project Management Office would be of benefit. In the case of my client it was a perfect storm of all of the following, see how many you recognise in your business.
1 - Groundhog Day Projects
In their words ... every project felt like they were re-inventing the wheel. The IT Projects this client was handling were roughly similar in scope, size and complexity and yet each time the Project team felt that they were starting from scratch. To outside eyes, there was clearly a point at which the project team could parachute in, they could stand on the shoulders of previous projects and use them as a startup template but, instead, every time a new project started it was "back to the drawing board" or “back to square one”.
2 - Bottlenecks
This firm has become very successful, very fast. At first, the business and its project team were easily handling the workload, but demand had ramped up way ahead of expectation and cracks had started to appear. Delivery dates were missed, work was late, mistakes were being made. Demand beyond forecasts is a lovely problem to have if you're set up to meet it. A Project management Office is not a silver bullet here but can help with more realistic planning horizons.
3 - Left Hand and Right Hand Had Become Strangers
This often happens when businesses expand ... Close knit teams who operated almost telepathically at the start begin to drop the baton. At this firm, there was no longer any real ownership or accountability, no clear idea what resource or expenditure was required to deliver each project.
4 - No Coherent Project Delivery Standards
This organisation was working on all the right projects. The issue wasn't project selection. When workloads were manageable, projects were being given the due care, attention and diligence so by default they were all delivered successfully. Sadly, as demand increased and resources got stretched there was no clear definition of what successful 'looked like'.
5 - Limited Transparency
Project Performance was hard to measure because of limited visibility. Again, in the early days, projects just got delivered because the team had breathing room but as things got busier it had become increasingly crucial to be able to dip into projects at different times to measure progress. A centralised PMO can give you on-demand snapshots of project progress against milestones.
6 - Capacity Planning/Limited Resources
When the business was set up the resources were adequate for the workload and the moderate growth that was forecast. As IT Projects were managed in isolation the business was finding accelerated expansion was creating real capacity planning issues. Selection and prioritisation of resources for projects was almost done on a "who shouts loudest" basis rather than any structured prioritisation.
7 - Attempts at Change Hit Brick Walls
This is a smart business. The Project team are seasoned professionals who could see that something had to change to meet the increased project demand. The problem is that everything they tried ... failed. Everyone was TOO busy to embrace change. When you need to push through change you need someone to own it, it needs process and governance. It needs a PMO.
8 - Burn Out of The Caped Super Heroes
When the business was in start-up mode, time and again, the same superheroes donned their capes and helped projects complete on time. When needed these staff Project Managers would work 50 or 60-hour weeks. This should have been a red flag because it isn't sustainable and as demand grew so did the need for the superheroes to step up but by now they were clocking 70-hour weeks and they were exhausted. When this starts to happen it's not long before even your heroes start to burn out and then what?
If your company is exhibiting signs like this (or others) you may need a fully functioning, end to end, PMO or just some considered adjustments to your current processes ... either way, if you feel that you need to improve project capabilities, we should talk.
The perfect storm described here is quite unusual and, for many, that is the problem. When it happens like this its sort of obvious that the processes and structure a Project Management Office brings are way overdue but when you only exhibit one or two of these signs or others like them, you tend to muddle through ... but be warned ... the perfect storm clouds could be gathering.
Find out more about Project Management as a Service from Stoneseed]]>
"But Scoro has a real-time dashboard for monitoring KPIs!" said a voice from inside the meeting room.
My ears pricked up.
"Yeah but Basecamp has great performance reporting too and the collaborative tools are way better!" replied one the people in the room.
"If it's collaboration that matters EventCollab wins hands down," countered another.
My client looked up from the conversation and acknowledge my arrival, "Here's a man who will know! David, what's the best Project tool for making lists of tasks and monitoring progress?"
I'm afraid I gave a politician's answer ... followed by an unashamed sell!
"It depends on the Project, the team, their maturity and what the most important outcomes are," I said, adding with a smile, "but if you're struggling to even agree on what tool works best I'd outsource the whole thing to a trusted Project Management as a Service partner."
Actually, this reminded me of a recent bit of office banter.
"Who still makes lists on paper?" asked a younger colleague.
The list she was referring to was a manifest of jobs I keep that need doing around the home. Now, when it comes to work lists and schedules I'm digital all the way but for personal and home I have always written stuff down - and I probably always will.
My younger colleague lists everything digitally both professional and personal and she showed me the app that she uses on her iPhone to organise her home chores.
The point is - that works for her but for my home "to do" lists, pen and paper suits me better.
In an attempt to win the "Who still makes lists on paper?" banter I turned to Google and, suitably pleased with my search, I triumphantly said, "Richard Branson."
In his blog post "How I Get Things Done", Richard Branson shares his top ten tips for making lists and getting things done and it seems that even Richard Branson carries a jotter everywhere! Last time I checked he was doing alright for himself. I've included a link to his blog at the end.
Actually, I know of one IT Project Manager who still manages day to day largely from paper, mostly because he works in construction IT and can't always get a satisfactory internet signal on-site but also, I suspect that this is what he prefers. Everything does get stored digitally when he gets within range of a WiFi router or a 4G transmitter but each day he prints off schedules, task lists and whatever else he needs to get stuff done and he carries it around. It works for him!
I also read of a Project Manager who carries everything in her head - apparently successfully too! No lists! How she does it, I have no idea. It scrambles my brain just thinking about it! I'd be terrified of forgetting something vital or worse stressing out members of my team. Actually, in this case, her team members are copious note takers and list makers so while she may boast of being list free it's not entirely true of the projects she leads. Having said that, she still carries a lot of project data and planning around mentally and her capacity to remember, recall and recite deadlines, scopes, budgets, etc, is very impressive.
She is, I suspect, the exception that proves the rule.
IT Project Managers with the greatest skills in this area tend not just to be the most organised but the most transparent too. I guess it stands to reason that in cases where everything is documented there is less likelihood of trying to cover your back by bending the truth. If it's all there in black and white you may as well be honest and transparent and focus your attention on what you are going to do to put things right rather than attempting to whitewash when things go wrong.
Well executed plans and lists can improve client communication, in fact, the best examples of where clients and stakeholders feel that they are "in the loop" are when project managers are efficient planners and listers. Projects that are thoroughly documented are the ones where status updates are at your fingertips and where milestones are measured and clear for all to see making it easier to communicate when they are met and when they are missed. Actually, missed milestones seem less of an issue when there is a clear plan in place!
It's worth repeating that line from earlier. You will get the best results from what works best for you and your project. The important thing is that it should feel totally natural, otherwise it's going to feel like a total chore!
If you find that planning and listing is a struggle it may be that you have not found the system that works best for you. An independent analysis of your Project Management operation can really help identify ways to improve or suggest systems and tools to try. Furthermore, with an ever expanding Project Management as a Service market at your disposal, you now easily can find people, tools and services that will complement your capability and fill any gaps or weaknesses.
I love the planning side of Project Management and I'm a big fan of lists, I even make lists before packing a holiday suitcase, much to the amusement of everyone who ever sees me do it.
Think about it though! While they're fretting about forgetting to pack something I'm nonchalantly ticking off items as they go in the case. All my "fretting" was done days back over a nice brew and a chocolate biscuit. Mentally, I've already packed my suitcase ...
... and it's the same with successful IT Projects.
I believe most of the success is in the efficient preparation and planning, the listing of tasks and the allocation of resources.Find out more about Project Management as a Service from Stoneseed
Key to the successful delivery of the IT for the London Olympics has been the establishment of a robust program and project management at the heart of a multisourcing framework. To read more on this story follow this link.]]>