3rd December 2007 When IT projects fail, technology is rarely the primary cause. For the vast majority, “people” factors – communication, experience, management and politics - are a far greater influence. This is especially true of planning system implementations, where cross-discipline project teams are essential to a robust solution. In the fourth of a series of six articles, FSN contributing editor Steve Bows presents the key planning project roles and outlines some practical management tips.
The Management Team
No matter how large or small the project, planning systems implementations stand or fall by the relationship between the three key roles, the project sponsor, solution architect, and project manager. Without the sponsor, there is no vision, without the architect, there is no plan, and without the project manager, there is no finished product. Let's look at these roles in more detail and examine the dynamics between them.
The sponsor is usually the initiator of the project, the visionary within the business who has identified the need for change and is prepared to do something about it. It is he or she who has chosen to take on the responsibility of seeing the project through to realisation, providing guidance on the business priorities to the project team, and resolving any conflicts in these priorities along the way. For example, conflict can arise regarding the level of detail at which the business should be planning. Some business managers will argue that a faster planning process requires a higher-level view, forecasting only at a summarised level of expenses, and others will argue that the subsequent loss of accuracy is material to the business. Who is right? Well, both are, but a decision needs to be made, and the project sponsor is the only person who can make it.
The solution architect is a project professional with many years of experience in planning systems implementations, and it is his or her role to ensure that all of these years of experience are reflected in the solution design. Every business faces a unique set of challenges, whether external or internal, but there is some common ground. Salary and expense planning tends to be fairly generic, and the solution architect carries a number of tools in the kitbag that can deal with most of these requirements. Revenue planning, however, tends to vary significantly across industry sectors, and it is wise to choose an architect with sector-specific experience to ensure the best solution. For all their experience, though, the key characteristics of a good planning system architect are flexibility and pragmatism – business requirements, and hence the best solution, are often unclear, conflicting and liable to rapid change as the business adapts its view of itself, and the architect needs to steer a sensible path through these to deliver a workable solution.
The project manager , ideally another seasoned project professional, has the job of tracking and communicating project progress, identifying issues and ensuring they are resolved, and generally keeping the project moving in the right direction. In particular, planning systems implementations require the modern technique of “agile” project management, in which changing goalposts can be quickly incorporated without bogging the team down in paperwork. In terms of the project tasks themselves, the project manager makes a choice at the outset of the project, depending on their own personal experience, as to how involved they want to be in the nitty-gritty of issue resolution – rolling their sleeves up and looking under the bonnet – but there are no hard and fast rules. After all, the primary task of the project manager is keeping all the project participants up to date, and this can easily be a full-time job in itself on a large project. On a medium-sized project, the project management role can often be combined with a technical architect role, complimenting the solution architect who tends to have more of a business-process focus.
It should be clear by now how important it is for these three people to work well together – each of them individually are necessary, but not sufficient, for project success. The sponsor must trust the expertise of the solution architect, and the information supplied by the project manager, but not expect them to make decisions on business requirements. The solution architect must not think that they have “all the answers”, but rather work with the sponsor to combine general experience with a specific vision. The project manager must place his or her faith in these two people rather than paperwork, but still have enough procedures in place to mitigate the usual project risks. It is a delicate balance, but when it works well, it can drive success in even the most difficult of projects.
The Supporting Cast
There are three main groups of project participants below the management team – the user representatives, the IT team, and the external consultants. A representative user group should be established early in the project to provide detailed requirements in support of the sponsor's vision. Carefully selected and managed by the sponsor for their business knowledge and alignment to the overall vision, this group are the team's eyes and ears in the wider business community, and should be used to champion the solution wherever possible. They also provide the final testing (UAT) sign-off, the last chance for quality assurance before the new process is unleashed, so having an eye for detail is a valuable asset.
The IT team is generally composed of two sub-groups on larger projects, infrastructure and applications. Infrastructure support is required on initial configuration of the development environment, and then in the run-up to go-live (this involvement will increase if a third environment – “test” or “UAT” – is also required). The project team will need preferential helpdesk access at other times, but usually not a dedicated staff member. Applications support tends to be more time-consuming, involving the analysis and integration of application-specific data to the new framework, and can easily become a full-time role. This time commitment will generally depend on the amount of in-house ETL (Extract, Transform, Load) experience, and how much needs to be provided by the external consultants.
Finally, external consultants should be used sparingly to fill out key skills shortages, which tend to be related to the new software package being implemented, but can also extend to the softer consulting skills of business analysis and end-user training. The solution architect, in most cases sourced from the same consulting organisation, will often manage this group. I will discuss the appropriate use of consultants a little more, and how to build in-house skills, in the final article of this series.
Although not as critical to the overall success of a project, the quality of, and dynamics between, all of these diverse team members play an important part in achieving specific project deliverables. Whilst appropriate levels of knowledge and experience are vital, it is a positive, “can-do”, attitude that makes the real difference, separating an exceptional achiever from an average performer irrespective of the project role. What's more, this attitude can be infectious – playing a part in delivering a radically new planning process is an exciting prospect, and this excitement rubs off on the other participants and eventual end-users. The converse, of course, is equally true: one negative individual in a project team can make life miserable for everyone and affect the all-important first impression of the end-users – and as we know, there is only one chance to create a good first impression.
Scoping the Project – Creating Good First Impressions
In planning implementations, as with most projects, a positive reception to the first set of deliverables drives the appetite for more, as the natural scepticism and resistance to change of the end-user community is gradually softened. In the next article we will look at how careful scoping of the first project phase can help the business digest the new process in manageable morsels whilst still delivering an integrated solution.
