Project Management at MASS

I was once told that Project Management involves just two things – deciding what needs to be done, then making sure it gets done.

This is like saying Physics is the study of matter and energy – it’s true, but kind of skimps on the detail!


A better definition, or more accurately framework, says that project management covers the management of eight areas – scope, cost, schedule, quality, risk, communication, HR and procurement.

Scope – what exactly are we delivering? How is it agreed with the client, and how will we manage any changes to the agreed scope?

Cost – creating a budget for the project and monitoring that we keep within it as we deliver.

Schedule – the timetable for delivery, with estimates for all the tasks, and resources (human and other) allocated to the tasks. Often represented in the famous Gantt chart (which many people think of as the core of project management) it also shows the inter-relationship and dependencies between tasks.



Quality – the project manager is responsible for the quality of what is delivered, normally by designing systems of testing and quality assurance that form part of the delivery.

Risk – Identifying risks to project delivery, likelihood and impact. Having a mitigation plan and monitoring them. (A risk is something which will delay or prevent delivery if it happens – an issue is something which is delaying delivery).

Communication – who needs to be communicated to about the project, by what mechanism and how frequently? This covers project progress meetings as well as updates to management and other stakeholders.

HR – Human Resources. What are the skills needed to deliver the project, and where will the people come from? Permanent or temporary, how do we find them, interview them, train them and incentivise them to deliver?

Procurement – do we need to buy anything in to complete the project? Goods or services? What contracts do we need to put in place, and how do we specify exactly what we need?


It sounds like a lot, but of course, the good news is that no project manager acts in isolation, and not many projects require all of these things from scratch.

Most mature organisations will have an infrastructure in place that covers some of these things, for instance: Existing staff, a purchasing department, a cycle of project meetings or management update mechanisms.

“I don’t know Phases….”

The same framework says that all projects are delivered in natural, overlapping phases – inception, planning, execution & monitoring, then finally closure.



As you may see from the above, the bulk of the “work” involved happens during execution, whilst the inception and planning are usually performed by the project manager and team leaders or other specialists.


Planning may not all be done at the beginning – we can only plan for what we know, and there may be some successive elaboration/detailing as the project progresses.


Having a defined and agreed Closure is very important to project profitability and customer satisfaction. Any organisation selling project work must be able to demonstrate that it has done what was agreed for the price, that a particular project has been delivered, and any new work forms a separate project or part of a maintenance agreement.


Project Management at MASS specifically

At MASS, projects vary from small, 3-4 person/day changes, to complete brand-new installations containing many person-years of work.


Typical tasks in such a new system would include hosting arrangements, application configuration, server configuration, installation, requirements workshops, specification writing, data extraction and loading, commissioning subcontractors for specialist services (e.g. asset collection), user training, database design and customisations involving bespoke development for database, web and apps.


One of the key aspects of being a project manager is deciding how much project management is necessary, tailoring the techniques above to suit the size of project being delivered.


There’s no point in using a sledgehammer to crack a nut, and overburdening the team with unnecessary plans and reporting requirements. At the same time, we need to know who is working on what, have we estimated the work correctly, and when will they be free for the next project.

It’s all about appropriate project management.


A large part of the role involves communicating with customers, initially about their requirements, then keeping them updated about delivery, together with risks and issues.

As we’re a comparatively small organisation, and I have a background in software development, I’m also able to help with designing and documenting some of the requirements, as well as a test strategy and process.


There is also resource management across the whole team, forward planning to make sure we have the right people on the right projects, and everyone is busy with something.

Finally, analysing how we performed, how well we estimated, and what we can learn for projects in the future.


Agile Methods

So, that’s pretty much about conventional “waterfall” project management, but a lot of software projects adopt an Agile approach these days.


Essentially, (thinking of the “Scrum” variety) this uses teams of 3 – 9 members, delivering product in an iterative fashion in time-limited sprints of 2-4 weeks. 


The features which make it into any given sprint are chosen from a backlog of user stories and issues, usually stored in a tool such as Atlassian’s Jira.


Once the sprint is defined, the team meet every morning for a quick stand-up meeting (Scrum) During the daily scrum, each team member typically answers three questions:

  • What did I complete yesterday that contributed to the team meeting our sprint goal?
  • What do I plan to complete today to contribute to the team meeting our sprint goal?
  • Do I see any impediment that could prevent me or the team from meeting our sprint goal?


Agile came about as a reaction to large IT projects taking a long time to deliver complete products, by which time the requirements were obsolete, or the market had changed so significantly as to make the product delivered irrelevant.


We have adopted some Agile techniques at MASS for some of the smaller projects, using Jira for issue recording and meeting every work day for a Scrum with the development team.

So far it’s proving a useful technique to give visibility to what the team are working on, avoid duplication of effort and help people collaborate where needed.



If you would like any more information regarding this blogs topic, please don't hesitate in contacting either myself or the MASS Technical Services Team. We are available on 0118 977 8560 or email us at


David Perkins 



MASS visited Dublin...again! 10/04/2019

Due to the success of 2018’s Dublin Roadshow, we just couldn’t resist making another visit to Dublin. This year, we hosted at the centrally located Temple Bar Hotel, which as the name sug...
read more view all blog posts