A featured contribution from Leadership Perspectives: a curated forum reserved for leaders nominated by our subscribers and vetted by the Construction Tech Review Advisory Board.

Enero Group [ASX: EGG]

Daniel OSheedy, Group IT Director

Project management in an SME environment

Daniel OSheedy

The project management methods that large organisations use have reached maturity, especially where IT projects are concerned. However, when SMEs run projects, these smaller organisations often experience execution difficulties. This is usually due to a lack of a skilled project team or a lack of formal project methods. These SME employees also find themselves in situations where they need to be more productive with scant resources, as companies try to ‘do more with less’ and team members are required to ‘wear more than one hat’.

A similar situation can be found in the software development field, where there are many refined methods and frameworks for the delivery of complex software projects. However small software teams often find these project methods bureaucratic and unwieldy, which has given rise to ‘agile’ software development methods, where the teams eschew process-heavy methods in favour of a more reactive style of software development. The focus is on producing a useful product for the business, while also allowing for requirement changes during the development process.

Enero Group is an international group of marketing and communications business, with around 600 staff working in 14 cities around the world. We are a boutique force in the market, and as such, can be more nimble than some of our competitors. One of the tools we use is a customised, agile project management framework to improve the implementation of IT projects. This framework takes core concepts from the PMBOK (Project Management Book of Knowledge) in addition to ideas taken from action research and agile software development. The resulting agile framework helps project teams working in fast-paced environments, where there is often a need to respond quickly to requirement changes.

Here’s the framework in a bit more detail:

At the start of each project, goals are clarified with the project stakeholders, and the project objectives are set. If the product is experimental or unique, a detailed objective may not be definable at this stage, but at a minimum, the goals for the first cycle need to be defined.

These objectives are used to build out the project backlog (a list of prioritised tasks to achieve the project goals), which is used as the input for the action cycles.

Next is the action cycle stage, where the work is broken into four phases. The goals for the current cycle are set using the backlog tasks as the input, with the team agreeing how task success is determined. The second phase involves planning the tasks, which are assigned to the appropriate individual or team, conditional on the size of the task.

The third phase is where the action happens! A long-term project might have cycles lasting a week or more, whereas a short project can have cycles lasting just a day or two.

It’s also during this phase that the project team takes the time to stop and assess the task progress, and ensure that there’s no drift from the project goals. As cycle times are variable, so the feedback iterations are variable. For example, an ‘act’ phase implemented over weeks will benefit from daily feedback, whereas a more time-intensive project may require more frequent feedback iterations, especially for high-risk projects.

The final phase is important, but one that is often neglected. The team has a look at the work just completed and determines whether the goals were reached. If the goals were not achieved, the team will need to troubleshoot what went wrong, and how it could have been improved. This stage is vital, as an agile project management framework must react quickly and positively to change in order to adapt to and overcome changing issues.

Each cycle produces a usable portion of the desired end result, and therefore this framework is more suited to a project where deliverables can be completed and used in an incremental manner. Project stakeholders are able to use these segments of the end product as they are finished, rather than waiting until the end of the project.

The agile project management framework helps us improve project delivery success at Enero Group, allowing the IT project team to be more flexible and reactive when requirements change mid-project. There are critics of agile frameworks, of course, and they argue that this style of framework has fewer controls and less accountability, and that project teams can quickly run into issues with scope creep and budget overrun. Whilst agile project management is less bureaucratic by design, it is possible to layer the controls using traditional project management tools. The project manager will determine the project’s complexity and risk level of the project, to ascertain which tools are required. For a small scale project, a task-based board (as used in Scrum development) can provide sufficient control and work allocation, whereas a more complex project can require several traditional tools to help with the project management, such as work schedules, work breakdown structures, project resource scheduling. In the end, the project manager plays an essential part in setting the tools needed and is a pivotal function for the success of the project.

At Enero Group, we’ve found that we’ve been able to run smoother projects and can pivot quickly to changing requirements using this framework. I would strongly recommend people in small and medium-sized companies definitely examine this type of framework, as it can bring about some great benefits.

The articles from these contributors are based on their personal expertise and viewpoints, and do not necessarily reflect the opinions of their employers or affiliated organizations.