Tag Archives: business project management

Project Manager versus PMO Leader

Skills required to run a successful PMO

Project Management Offices (PMOs) are on the nose and for good reason. They are often conceived the Executive in a response to mounting need and requirement for the delivery of business changes, transformation or general improvement. They are more often than not headed up by senior IT staffers who have really no where else to go in an organisation’s hierarchy.  Rarely are they led by experienced PMs, strategists, and or entrepreneurial inspired talent.   Therein lies the core reason why so many fail.

Now, the role and importance of the PMO within business varies – for some it focuses on the project delivery level, for others it is at the strategic level. 

It is this wide variation in the types and remits of PMOs that has made their management taxing, challenging and complex to find the right leader with the right skill set. 

To run a successful PMO, you shall require the following skills:

  • ability to traverse both micro and macro agendas (and strategic imperatives/vision for the business)
  • strong analytical focus
  • keen eye for financials
  • delegation and team member autonomy (not micromanagement)
  • champion governance 
  • collaborate with other departments – to pool resources to deliver the most meaningful and coordinated results
  • vendor relations
  • staff development / mentoring

While working within a PMO can appeal to anyone, it is this diversity in roles that has made it difficult to clearly understand what makes a great PMO leader to bring it all together.

In my view, there is a lack of understanding about the range and types of skills & competencies required to work within and run a PMO. 

The attraction of a role in a PMO team is that it is multi-faceted from project management, team work, technical inputs, IT, vendor management, financial and budget management, time management, change management, internal stakeholder management & great oral and written communication etc

Interestingly, PMO leadership needs skills and experience not found exclusively in project management or IT fields.

Australian business needs to view PMO more as a separate business rather than in a conventional light.  This is supported by the trend to outsource PMO – breed from exactly the need to minimise budget wastage (in bloated and inefficient FTEs), diffuse or minimise risk by isolating it to the one entity (not across multiple departments) and focus on delivery of tactical and strategic goals of the business.

In my opinion, a PMO should be run by a SME CEO or MD – a person accustomed to doing a plethora of tasks and has a skill set that is akin with key skills and competencies required for overseeing, coordination and developing a team of differing backgrounds, strengths and skills into a thriving and successful PMO.

Eleventh Hour Checklist to help a PM before launching a new website

It’s a stressful time for PM’s on the eve of launch. Accordingly, Alisdair Blackman has devised a simple list or ‘checklist’ to help all PM’s check over the project prior to release/launch/go-live.

Project Checklist Prior to Website Launch

Standards and Validation

  • Accessibility
  • HTML validation
  • JavaScript validation
  • CSS validation

Search Engine Visibility, SEO and Metrics

  • Page Titles are important; ensure they make sense and have relevant keywords in them.
  • Create metadata descriptions for important pages.
  • Check for canonical domain issues (e.g. variations in links to http://site.com.au http://www.site.com.au http://www.site.com.au/index.html should be reduced to a single consistent style)
  • Ensure content is marked-up semantically/correctly.
  • Check for target keyword usage in general content
  • Check format (user/search engine friendliness) of URLs
  • Set up Analytics, FeedBurner, and any other packages for measuring ongoing success
  • Create an XML Sitemap
  • Configure Google Webmaster Console and Yahoo! Site Explorer

Functional Testing

  • Check all bespoke/complex functionality
  • Check search functionality (including relevance of results)
  • Check on common variations of browser (Internet Explorer, Firefox, Safari, Chrome etc.), version (6, 7, 2.2, 3.1 etc.) and platform (Windows, OSX, Linux)
  • Check on common variations of Screen Resolution
  • Test all forms (e.g. contact us, blog comments), including anti-spam features, response emails/text, etc.
  • Test without JavaScript, Flash, and other plug-ins
  • Check all external links are valid


  • Configure backup schedule, and test recovery from backup.
  • Protect any sensitive pages (e.g. administration area)
  • Use robots.txt where necessary
  • Security/Penetration test
  • Turn-off verbose error reporting
  • Check disk space/capacity
  • Set-up email/SMS monitoring/alerts (e.g. for errors, server warnings); consider internal and external monitoring services


  • Load test Check image optimisation
  • Check and implement caching where necessary
  • Check total page size/download time Minify/compress static (JavaScript/HTML/CSS) files
  • Optimise your CSS: use short image paths; make full-use ‘cascading’ nature of CSS, etc.
  • Check correct database indexing
  • Check configuration at every level (Web server, Database, any other software e.g. Content Management System)
  • Configure server-based logging/measurement tools (e.g. database/web server logging)

Finishing Touches

  • Create custom 404/error pages
  • Create a favicon

Technical & Business Project Delivery Methods

The key to the delivery of a good project lies in the methodology adopted by the project manager.  If the method is sound, the risks for the project are well known and thus can be properly managed.

A good PMO (project management office) will lean on either internal resources or more commonly expert, specialist consultants like Digital Rehab to provide agile project management services. The methodology however should be instigated and policed by the PMO so as to ensure consistency in project status reporting and documentation.

From over 18 years experience running hundreds of medium to large scale projects, here are some of my tips and recommendations on how best to deliver web projects (be they websites or applications).

Documentation is a critical success factor behind a good project

From the outset make sure that all relevant documents are in place.  In my opinion these documents should include:

  1. business case – this document is used to legitimise the reasoning for the project and usually includes cost benefit analysis, market pressures, summary of objectives, high level scope, financials (investment required, pay-back, other factors), resource utilisation, risks, success criteria/measures etc
  2. business requirements – this document is to be used to underpin all decisions around scope and functionality. It also serves to articulate a businesses objectives.
  3. project plan – outlining the key milestones or phases of the project, individual “micro” work tasks, responsibilities, risk level, and dependencies.
  4. project timeline – Time is one of the critical factors often in a project. Your ability to deliver to the timeline originally outlined, committed to will be one the key yardsticks used to judge the overall competency of a project manager. It therefore is critical that this be a document that breaks all work tasks down and complements what has been included in the project plan.
  5. project budget – a project budget however big or small will need to be closely managed by the project coordinator/manager. I have found that a good budget should look to include the following work sheets: Project Budget Snapshot (outlining total budget or budget phasing versus actuals committed/PO’ed against remaining budget), Approved Budget (listing the phasing, budget approved), Budget versus Actuals (showing a monthly breakdown of how the approved budget is tracking against actuals, where actuals are the costs either committed to or invoiced, identify the delta or difference between budget versus actuals and contigencies)
  6. risk register – this document plots all known risks that may be incurred/experienced over the course of the delivery of the project.
  7. decision register – this document serves to log all key decisions that have impacted the project often including such things as decision owner, decision taken, decision date, decision consequences etc.
  8. solution design – this document maps out the solution architecture for the project.  How this project fits within the broader IT landscape and architectural vision of a business.  It looks at issues including but not limited to security, access, infrastructure, integration points, database configuration, performance, scalability, re-usability etc.
  9. wireframes – these are schematics for how the solution should be structured from a layout / configuration and visual standpoint.  It is at this time that your solution comes to life and can be socialised for internal / external review.
  10. front and backend designs (GUI) – these are the final visuals to be used during the build to provide both a front end and back end for the solution.
  11. scope specification – this is often performed by a vendor with close controls and input from internal IT. The purpose of this document is to accompany the wireframes and designs and talk at how they should be built, with what interlinkages and how they should be controlled/managed.  From this the ‘build’ or development / execution can be informed.
  12. launch strategy / deployment guides – these documents should be crafted to plan out the launch of a new solution – who shall be responsible, for what, when.  It should also include a communications plan for how the new solution will be marketed / embraced / delivered to its intended audiences.  A deployment guide should always accompany the launch strategy which serves to help with IT’s ability to understand how to deploy the application/solution again in the future without the need for a vendor to again be engaged to perform the task.

Ensure project delivery methodology and milestones broadly conform with a proven approach 

I would recommend that the following delivery methodology be used:

  1. DEFINE & SCOPE (occasionally referred to as ‘Initiation’)
  2. SPECIFY & DESIGN (also called ‘Planning’)
  3. DEVELOP (also known as ‘Execution’)
  4. TEST & LAUNCH (called ‘Delivery’)

This methodology and project phasing is important so as to ensure a business/client/key stakeholders have had sufficient levels of consultation, input, controls and approval gates so as to ensure the project satisfies its intended purpose and objectives.  Breaking the project into these milestones enables the project to be thoroughly managed and for clear checkpoints to be in place to help guide work tasks.

There is ofcourse other prevailing and dominant project methodologies – referred to as ‘waterfall’ or ‘agile’ – see below:

waterfall vs agile diagram by Digital Rehab

I personally prefer a hybrid of these two rather than being a purist to any one method.

This article was written by Alisdair Blackman.