Completers are concerned with wrapping projects up. Usually, completers are not very good at getting things started but they are great at coming in and sorting out a mess, getting it back on track and getting it completed.
Get this done.
Having a completer on the team is essential to getting to he end of a project. As a project proceeds they tend to get more diffuse and with software new ideas, implementation, training and user engagement are all essential. There is a need for an attention to detail and the tracking of minutiae. This type love all that. They love making lists and ticking things off.
They often are great diplomats as any project that goes on for some time brings out the character traits of all involved and can lead to conflict. People who appeared to work well together cease to do so. This type is good at settling disputes and smoothing operations whilst keeping their eye on project completion.
Depending on when the project is taken over by a completer they can put up considerable obstruction to any changes that become obvious and beneficial as these will lead to the delay in completion. Since the focus is on completion and not necessarily on relevance and functionality some of these desired and required changes may not be “allowed” to be implemented. This may lead to issues later when the boss asks where the desired feature is, or by the end users who indicate that they cannot do their job without the feature or function.
With an obsession to complete these types may not be “available” to consider the next project until this one has been done. This can lead to long lag times between one project and the next.
I was in a meeting where the final version of a software project was being presented to the company and the boss asked where a belatedly added key feature was. I replied that it had not been implemented on the instructions of the project manger, as it would have delayed the project. He was not best pleased and there was upset by the end-users who then demonstrated just why the absence of the feature meant that continuing the presentation was pointless.
We met again 2 weeks later when the function had been added. The delay meant that some staff who had been employed to run the system needed to be found other duties whilst the function was inserted. The costs were considerable.
With a strict completer, and one who is not the intended end user, it is important to have an enduser test the system and ensure that it not only meets the brief but also does what they need it to do. The brief should always be carefully constructed and reviewed but, despite that, there will be some issues that only become apparent as the project is worked on. Having an enduser try it out just makes sense. If suggestions for changes are made (and they will be as all endusers love to contribute ideas) any decision to implement or delay the suggestion should be run past the users so that the impact of the include/postpone/exclude decision can be determined.