Category Archives: Project Services

Project Services section

A vision of the future of project management?

Leave a Reply

It’s the first day of EDUCAUSE 2017 in Philadelphia and Michio Kaku took us on a mental journey to a possible version of a digitised future. This got us thinking about what the project management profession may be like in his version of the future.

In his presentation Michio, a theoretical physicist and futurist, proposed how technology and digitisation might change the world in the not so distant future.  Through speaking to hundreds of scientists from different fields Michio has concluded that tech will be everywhere in our daily lives from AI nurses, digital wallpaper that could host virtual meetings to contact lenses with internet access.

Although young people’s desire for innovation is pushing developments in tech, Michio predicts that, with aging populations, AI will start to advance at greater speed. This is evidenced in Japan where the fastest aging population in the world is pushing innovation and development in this area, particularly in the health sector. 

This talk got us thinking about whether Project management could be replaced by AI where trend based analysis could improve project techniques such as planning or risk management. In these areas removing emotions and basing decisions on facts could improve the outcome of project delivery.

However (thankfully) project management is not just about administration. Michio stressed that a computers strength for repetitive tasks and calculations are unlikely to ever be able to replicate intellectual capital such as a humans ability to support, provide leadership and imagine new possibilities required for true innovation. These soft skills are the ones already needed for good project and change management but it seems they may become even more important if the profession is to survive.

So for now, technology advancements and AI might enhance the project managers ability to collaborate and deliver the project but if we evolve in to project and change leaders rather than managers our jobs would seem to be safe for now (phew!). 

https://events.educause.edu/annual-conference

Making project management more digestible

Leave a Reply

1 Laying the foundations

The Project Management Office (PMO) in Project Services offers full-day project management training courses, but many of our staff find it difficult to free-up that amount of time in their busy diaries.  So the PMO has developed a series of ‘bite-size’ lunchtime sessions that staff are able to more easily incorporate into their working day.

The bite-size sessions break down the content of the full day course into four easily-digestible  one hour sessions.  The sessions are free to attend and are advertised via the Events channel on our University portal, MyEd.  Staff can choose to attend one or all of the 4 sessions, which include: –

  1. Laying the foundations – Understanding how clearly defining your project with a Project Brief will help to give your project a firm foundation for success
  2. Planning the journey – How to put together a realistic project plan, including the 3-point estimation technique
  3. Adapt & survive – Understanding the importance of risk management and what to do when things change or go wrong
  4. Right people, right message – Engaging people in your project and getting the right support

The next set of bite-size sessions is scheduled for October 2016 so if you’re interested in attending please keep an eye on MyEd.

 

When Annual doesn’t mean every year

Leave a Reply

Watching the BBC programme “Forces of Nature” made me think about why the challenges of “Annual”  Projects should not be under-estimated. The programme explained that as the Earth travels around the sun – it never, ever returns to the same place. Even the orbit of the earth isn’t “annual” in the way I thought it was. This video illustrates nicely

Annual projects are not crowd pleasers.

When my children were small I used to buy them the children’s newspaper: “First News”. Each week a small section featuring political events squeezed in amongst the stories about space and animals and pop stars. This had the woebegone title: “Boring but Important”.

Every organisation has projects like this and they never feature in annual reports or get people excited – unless they don’t deliver.

This post celebrates “boring but important” annual projects and the project teams who deliver them! Here’s one example.

Each year IS Applications and the Timetabling Unit work together on the Timetabling Annual Roll-Forward. We work on it all year, for the “roll-forward” is not one task but many. It takes place not in one fell swoop but in several stages throughout the year. Every year.

Almost as soon as the academic year begins, staff throughout the university start preparing for the next one.

In the autumn the database on which next year’s timetable will be built is prepared and made available to time-tablers.  By New Year, room-booking for the next academic year is opened up to staff.

In the spring, applicants for the forthcoming year are added to the new database. In the summer, continuing students who have passed their exams are loaded.

Finally at the end of summer, the new academic year officially starts and all remaining services (such as student room booking and the screens outside lecture theatres) are updated to reflect this.

Surely this work should be “business as usual”. Why does it need to be a project? After all, didn’t I just say it happens every year?

But  it’s never the same.

Firstly, we work hard to develop the services provided to our staff and students, and to provide new ones. This means the “annual” process is always changing as the services putting data into timetabling or taking feeds from timetabling grow in number and complexity.

Secondly, the drive for efficiency and our own professional pride dictates that we want to make the roll-forward processes cheaper, smoother, faster, more reliable and more repeatable.

This year the timetabling service was upgraded to a new version and the project team  used this opportunity to build in automation to parts of the roll-forward processes. This will ensure quicker, smoother delivery in the future.

Yes, the academic year has its seasons: students apply for places and enrol on courses, courses are added or dropped, teaching rooms are changed or repurposed, staff come and go, exams are held, graduations are celebrated.

planets moving through spaceBut although these events  may be fixed, the underlying processes which deliver them are not. It is the unglamorous job of businesses and project teams to ensure they are delivered, even as the earth spirals forwards in spacetime and a project team looks for some poetry in an annual  roll-forward project.

Morna Findlay

When is a project not a project?

Leave a Reply

Not a project

One of the questions that we’re often asked here in Project Services is “when is a project not a project?” or to be more specific “when is it worth treating a piece of work as a project & when isn’t it?”.

Sometimes the answer is fairly obvious – if it’s a small and simple piece of work, taking just a few days, and involving just one or two people, then it probably makes sense to just treat this as a routine task.

But not all answers are as clear as that: –

  • What if it’s a bigger piece of work?  At what size should it become a Project? 10 days? 25 days? 100 days?
  • What if it’s a small project but is more complex and affects multiple areas of the University?  Or has inter-dependencies with other work?
  • What if it has financial or timeline implications that need to be managed?

Any of these factors could potentially mean that it would benefit from having the control and rigour that project management processes bring.

So in reality there’s no one single measure that clearly differentiates between what could be simply treated as a routine task and what is worth treating as a project.  The simple answer is “it depends”.

So how can you decide?  We recently undertook an exercise with colleagues from MVM to help them answer this question.  Together we created a decision tree (shown below) that helps them to quickly and easily evaluate each new piece of work and to determine whether to treat is at a project or not.

What do you think would be the key factors for a decision tree in your area?

CMVM project decision tree - image

 

New shared Agile resources

Leave a Reply

Why did we develop these resources?

We saw the advantages of using Agile techniques, but the established frameworks didn’t sit well with our existing project processes. We cherry-picked the elements of Agile that we felt would work for us and pulled them together into our own take on Agile.  We’ve learned from our experiences over the last  years and we are now keen to share our experiences with others.

These resources were developed by Dawn Holmes from Project Services and Bill Lee from Software Development.

“This framework is a valuable resource for anyone starting out with Agile. Based on Scrum and developed by IS Apps over many years to fit into University practices” – Bill Lee

What is Agile?

Agile is a framework based on iterative and incremental software development where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. It promotes adaptive planning, evolutionary development and delivery, a time-boxed iterative approach, and encourages rapid and flexible response to change

Why use it?

There are times when a more traditional approach to developing services isn’t efficient. Perhaps it’s a new service where detailed requirements aren’t yet clear, or there’s a need to get a simple service up & working quickly whilst the more advanced features can be delivered over time.  Under these circumstances a more iterative & incremental approach to developing the software would be more appropriate. This helps to deliver a quicker return on investment.

Agile ROI

Framework for Agile

In IS Applications, we have developed our own Agile framework, taking elements of best practise from several recognised frameworks such as Scrum, XP and DSDM (Atern).  it is a collection of Agile techniques and practices which abide by the Agile Manifesto and the 12 principles of Agile.

principlescropped

Which projects work best with Agile?

It works best on software development projects where there is a discreet new solution required. Agile techniques can be used on other types of projects but it lends itself more readily where you’re developing something from scratch.

A second key condition for success relates to the iterative nature of Agile. This approach allows the business partners to see the solution evolve and mould the outcome through close collaboration with the project team. A close working relationship is particularly important on an Agile project where the software is developed incrementally and needs frequent decisions and input from the business..

Agile decision tree

How do I find out more?

By accessing our free Agile resources page here

 

Simple Project Portfolio Management

2 Replies

Typically we have many more ideas for projects than we have resources to execute them. We need some simple processes to determine what projects to take on.

Agreeing priorities for your projects when you have multiple different stakeholders can be difficult – comparing the relative priorities of new and in-flight projects can be even more challenging. Do nothing and you may miss opportunities to optimise benefits from your project portfolio. Become too interventionist and you risk continually stopping and starting projects which makes no one happy. If you introduce too complex a process then you may become over bureaucratic and create a project governance industry at your institution. It can be a minefield!

Here are some suggestions that we’ve adopted at the University of Edinburgh to provide some simple Project Portfolio Management capabilities.

Suggestion 1 – Assign all your projects an Overall Priority when you bring them into the portfolio

First-Link-Priority2-264x300We assign each new project or proposal one of the following Overall Priorities as part our planning process:

CRITICAL (Priority 1) – typically failure to progress these projects will:

  • Have unacceptable impact on the University community, e.g. affect a large number of students, staff, visitors or alumni
  • Involve unacceptable additional costs, e.g. the costs of providing an alternative solution or for additional goods and/or services which would not otherwise be required
  • Place the business of the University at unacceptable level of risk, e.g. failure to meet a legislative requirement or deliver a contracted service
  • Cause reputational damage to the University

HIGH (Priority 2) – typically failure to progress these projects will:

  • Have significant impact on the University community
  • Involve significant additional costs
  • Place the business of the University or an organisational unit at significant risk
  • Cause significant reputational damage to Information Services, our partner or another organisational unit

MEDIUM (Priority 3) – typically failure to progress these projects will:

  • Impact on the University community
  • Involve additional costs
  • Place the business of an organisational unit at risk
  • Cause possible reputational damage to Information Services, our partner or another organisational unit

Due to sustained levels of demand for projects we haven’t needed to define a LOW (Priority 4) classification for a number of years!

The initial Overall Priority allocation for each project is based on the judgement of the Project Sponsor and is reviewed by our management team as part of the project take-on process. Overall Priority allocations for projects in our portfolio are reviewed at least quarterly by our senior management team. Any proposal to change Overall Priority for a project is discussed with the Project Sponsor prior to the change being made.

There is  an agreed mechanism whereby a Project Sponsor can request an change in Overall Priority at any time – again with appropriate senior management oversight to adjudicate on requests. Overall Priority can also be affected by the stage the project is at. For example we may want to protect a project that is very near to going LIVE by giving it a higher priority. Projects with a longer lead time may start off with a lower Overall Priority and be stepped up later.

Setting Overall Priority for all the projects in our portfolio enables us to identify the most important projects that we are currently working on.  When a schedule or resource conflict arises and we have to choose between projects we use the current Overall Priority of each project to guide our decision making.

Suggestion 2 – Score all your projects when you bring them into the portfolio

mental_gymnasticsWe score our project proposals to define our portfolio in the first place, i.e. to determine which projects to take into the portfolio. This is a really valuable technique for identifying which projects to work on and why.  We also use Portfolio Score to compare between projects with the same Overall Priority.

Our approach is to score our projects against a few simple factors. We then use these Portfolio Scores to prioritise projects. We keep the scoring simple and score projects at the outset, as they come into the portfolio, rather than more frequently.

Our Portfolio Scoring for each project is based on the following weighted factors:

  • Alignment with University Strategic Plan 0 = Not Aligned, 1 = Somewhat Aligned, 2 = Fully Aligned i.e. of clear strategic importance (Weighting = x3)
  • Risk of not doing the project High = 3, Medium = 2, Low = 1, None = 0 (Weighting = x2)
  • Benefit to cost ratio >2 = 2, 1-2 = 1, <1 or Not Stated = 0 (Weighting = x2)
  • Time to deliver tangible benefit <1 Year = 3, 1-2 Years = 2, >2 Years = 1 (Weighting = x1)

For the benefit to cost ratio we consider the direct financial benefits to be delivered by the project with the costs of delivering the project, including any associated service costs, over a period of four years.

We could add more factors but we are wary of double counting and adding unnecessary complexity. The Portfolio Scores can be differently weighted, e.g. to value strategic alignment more highly than benefit, depending on our requirements at that time. Its obviously important however to use the same weighting for all current projects so that the scoring is directly comparable between projects!

We use the Portfolio Scores to decide which projects to take forward and to inform portfolio level decisions, e.g in the event of resource or schedule conflicts, based on both Portfolio Score and Overall Priority

 Suggestion 3 – Establish portfolio level project governance

meeting21You need some form of overall governance approach to use these tools effectively. If you are deciding between projects for a single business area then it’s easy. If you are  delivering projects for partners across the University then more senior management involvement will be needed.

At the University we’ve found that involving the senior management team, e.g. Heads of College and Support Groups, in defining the initial project portfolio is essential. After that, and as long as senior management understand the process,  they will typically be happy to trust the Head of IS  or Head of PMO to oversee operational decisions with escalation only required in exceptional circumstances.

We need to keep the senior team informed of current portfolio status and do this through quarterly status reports which include Overall Priority and current RAG status. For larger projects we also have local governance, typically a Project Board or Steering Group, to help ensure that the impact of decisions is understood and informs what we do.

I hope the above suggestions are helpful. Please let me know what you think!

Mark Ritchie
Deputy Director and Head of Project Services

Project Management in IS Applications FAQ Part 1 – Tools and Metrics

Leave a Reply

In my role as Head of Project Services I’m often asked about what tools and approaches we use for project management in IS Applications. These questions have become more frequent since I became Chair of the UCISA Project and Change Management Group in 2014 see https://www.ucisa.ac.uk/groups/pcmg.aspx.

This is the first of an occasional series of posts which I’ll try to provide answers to the most frequently asked questions. This set of questions cover aspects of project management tools and metrics and was developed in response to questions posed by Trinity College Dublin.

1 – What tool do you use for Project Portfolio Management (PPM)?

We manage projects and resources in ASTA PowerProject http://www.astadev.com/ We capture actual project effort for IS Applications Division Staff staff using the web based  time recording tool provided with ASTA.

A complete time record is submitted by each person in IS Applications Division each week which includes their effort on projects, services, annual leave, absences and other activities. ASTA PowerProject is a specialist tool and most of our staff only access the too via the web based Time Recording interface. Our full ASTA users are Project Managers, Programme Managers, Portfolio Managers and Resource Managers within our various teams.

2 – What tool do you use for project/portfolio reporting? (in terms of metrics/trends)

We capture actual project staff effort in ASTA PowerProject http://www.astadev.com/. We export this data to Excel and our formal reports on projects, services and resources are all driven from the ASTA data.

3 – Do you have a repository for PM documentation? If so what do you use.

Our repository is the Drupal based web application at www.projects.ed.ac.uk we also use Confluence Wiki and SharePoint for sharing project information and managing Project Boards, and User Groups.

4 – How do you measure the success of the PMO/Governance structure? And would you have any metrics you could share on this?

Currently our measurement is mainly around projects delivered – we need to do more with outcomes and benefits.

Our projects are grouped into programmes and portfolios. We have an annual planning process to identify projects see https://www.projects.ed.ac.uk/planning/area/apps/15-16. The outcome of the annual planning process is an agreed set of projects to be delivered in the coming year. We know how many projects are expected to be completed in the year ahead for each programme and portfolio.As part of the planning process we set a budget for our staff effort on each project and can roll up this to set a budget for each programme and portfolio.We also capture start, planning, delivery and closure milestones for each project.

We use these measures to report metrics and KPIs including:

  • Number of projects delivered in a period by programme and portfolio
  • Number of project days delivered in a period by programme and portfolio
  • Number of projects delivered as a % of the expected number of projects to be delivered in a period by programme and portfolio
  • Number of project days delivered as a % of the expected no of project days to be delivered in a period by programme and portfolio
  • Number of key project milestones (start, planning, delivery, closure) achieved in a period by programme and portfolio
  • Number of key project milestones (start, planning, delivery, closure) achieved as a % of the expected number of key project milestones to be delivered in a period by programme and portfolio

As we have a budgeted effort for each project we can compare budgets with actuals on a project, programme, portfolio or overall basis. This is great – but be need to be wary of becoming overly fixated on costs rather than project outcomes.

We capture a RAG status for each project based on very simple rules:

GREEN – expected to deliver agreed scope on time and in budget
AMBER – emerging risks or issues may not deliver agreed scope on time and in budget
RED – will not deliver agreed scope on time and in budget (intervention required)

Our primary interest is in the RAG status for individual projects. For large programmes and portfolios however we occasionally report counts and percentages of projects by RAG status

We publish annual reports for each portfolio which contain some of this data. You can view reports of portfolio outcomes in 2013/14 in the portfolio home pages on the Projects Web Site:

5 – Any thoughts on developing these metrics?

The thing we are all looking for is the correlation between project outcomes and things which we can influence or control. We all want answers to questions such as:

  • are we more or less successful with small, medium, large or extra large projects?
  • are we more or less successful on projects with shorter duration/elapsed time?
  • are we more or less successful on projects of different types e.g. Software Development, IT Infrastructure, Software Package Implementation, Business Case/Options Appraisal and Procurement?
  • …..

This requires us to regularly review project outcomes against various measures including project size, duration and type as part of our continuous improvement processes.

References

We’ve also contributed to the following best practice project and change management resources published by UCISA:

Mark Ritchie
Deputy Director and Head of Project Services