Elements of TPM used in the study

With the existence of the PMI’s PMBOK guide as the basis for all traditional project management, there seems to be a strong agreement among the researchers and practitioners, as to what constitutes project management (Papke-Shields et al, 2009); however, disagreements arise in the way these elements are interpreted in practice (Alleman, 2008).

In the melee of this confusion defenders of the PMBOK guide argue that the bodies of knowledge on which TPM is premised do not recommend a specific method of executing a project (Saladis and Kerzner, 2009), whilst on the other hand those calling for a revision of the PMBOK (Fitsilis, 2008) argue that the guidelines given in these bodies of knowledge sometimes act as methods for project implementation. For instance Alleman (2008) on the Niwot Ridge Consulting website argues that the PMBOK guide describes the various ‘components’ of a project and how they are related which are taken as examples for recommendation. On the contrary a look at the PMBOK shows that the guide always leave room for different types of project execution methods, especially when one considers their reference to the effect of project environment and the need for iterations in some instances. Nonetheless, the PMBOK’s recommendations were taken as a useful basis upon which to establish elements that can be helpful in the identification of TPM presence in consulting firms.

According to PMI (2004) a project can be decomposed into five processes i.e. initiating, planning, executing, monitoring and controlling, and closing. As discussed above almost all scholars agree on these phases but it is on their interpretation that they tend to diverge. In the wake of the recent successes for the Sydney Opera House (that was initially regarded as a failure based on the triple constraints) (Hällgren and Wilson, 2008), this confusion has also extended into the debate on what constitutes project success (Atkinson, 1999). This is so because the PMBOK’s success is mainly hinged on the iron triangle (project scope, time and cost) but recent developments show that these are not enough for measuring success (PapkeShields et al, 2009; Shenhar, 2004), one has also to consider dimensions such as business results and preparing for the future (Sauser et al, 2009; Saladis and Kerzner, 2009).

The PMBOK also gives nine knowledge areas of project management; these are integration management, scope management, time management, cost management, quality management, human resource management, communication management, risk management and project procurement. Since APM seems to borrow from some of these areas (Frye, 2009), to distinguish TPM from APM, this thesis focused on scope management, time management, communications management and integration management.

TPM emphasises the need for having 5 process groups i.e. the initiating process group, planning process group, executing process group, monitoring and controlling process group as well as the closing process group (PMI, 2004). These process groups were used to describe some of the elements of TPM. The TPM elements that were identified in literature, though not exhaustive include rigid or detailed planning/control procedures, Tasks breakdown and allocation, religious adherences to milestones, employees can be changed easily, Predetermined stakeholder requirements and command and control leadership style. It must be noted that not all the elements need to be present for the type of project management to be regarded as TPM. Each of these elements will be explored in turn.

a) Rigid and detailed planning

TPM stresses on the need to create a detailed plan (Shenhar, 2004) which is important for developing the project budget and schedule (Saladis and Kerzner, 2009). According to PMBOK, once the project plan is in place from the planning process group, it becomes the bases upon which the project will be planned, executed, monitored, controlled and closed.

This brings in the element of rigidity because the plan will be so detailed such that any changes will have to follow a formal procedure (Conforto and Amaral, 2008; Fitsilis, 2008; Schuh, 2005). The executing process group, although they can propose changes they are not empowered to approve them. They have to seek approval from senior management. However, formal procedures of monitoring and control accompanied by a good detailed plan in TPM is sometimes an advantage, for example Saladis and Kerzner (2009) argue that it helps to avoid confusion, scope drift, and scope ‘leap’ as well as conflict among the stakeholders. Therefore the choice of what type of plan and control procedures to use should merely depend on the context and preference because the conventional methods like APM are sometimes affected by these disadvantages due increased freedom associated with them (Fitsilis, 2008). Rigid and detailed planning also connotes adherence to milesones. In most cases TPM makes use of a linear execution of activities following detailed plans that were developed in the early stages of the project life cycle (Weinstein, 2009). The monitoring and controlling process group is responsible for measuring progress and identifying variances from the project management plan so that corrective measures can be taken.

This according to PMI (2004) as well as Saladis & Kerzner (2009) increases the chances of the project being delivered on time which is a critical delivery requirement. It can also be argued that the setting of milestones helps in keeping project mangers focused. Considering that consulting firms normally operate within tight schedules, then adherence to milestones may be essential to their work. However, this adherence to milestones is also criticised for neglecting the effect of complexities and uncertainties (Schuh, 2005; Owen et al, 2006; Conforto and Amaral, 2008). Therefore there are certain instances where adherence to milestones are useful and vice versa.

b) Task breakdown and allocation

TPM uses a deterministic reductionist approach and a detailed documentation of every process (Weinstein, 2009; Rodrigues and Bowers, 1996). It makes use of the project and work breakdown structures, activity definition and sequencing. This is said to be useful for breaking down projects into suitable components, resource allocation as well as defining milestones and decision points (Saladis and Kerzner, 2009). This is something important even for APM. However, it is the degree to which tasks will be broken down that Schuh (2005) is opposed to. In this school of thought lies the argument by Sodhi and Sodhi (2001) that the waterfall model is cumbersome because it involves a number of successive steps which may be detrimental to project delivery in the fast paced world. TPM’s task breakdown approach is also criticised for being based on predictability, stable requirements and previous experiences (Fitsilis, 2008; Rodrigues and Bowers, 1996).

c) Employees can be changed

According to Elliot (2008) with TPM employees can be easily changed within the organisation. This may have the advantage of ensuring that replacements are always available and that employees get more acquainted with the organisation’s operations. On the contrary it can also be criticised on the basis of possible demoralisation on employees. In addition since employees are seen as organisational ‘machine parts’ they may lose commitment to the firm’s activities. For this reason TPM is sometimes referred to as less people focused (Rodrigues and Bowers, 1996). (Griffiths (2007) argues that it is important to see employees as stakeholders to avoid this problem.

d) Command and control leadership style

In most cases the project manager under TPM is responsible for planning and allocating tasks (Kerzner, 2003). According to Larman (2004) pre-planned rules on team roles and responsibilities, team organisation, relationships and activities are crucial in TPM’s project control and leadership approach. This has the advantage of making sure that someone is always accountable for the project and ensuring that control is exercised to keep the project on track (Saladis and Kerzner, 2009). However, this management can also be criticised on the basis of the project manager’s limited cooperation and communication with the team and the client during the process that may lead to an oversight and misunderstanding the customer requirements (Tomaszewski and Berander, 2008; Atkinson et al, 2006).

Therefore, considering that TPM is still in use even with all the criticisms that it receives together with the effort being put in its modification it seems like TPM will continue to play a significant role in industry because of its merits mentioned above. However, its shortcomings mainly in the face of unpredictable and complex environments call for an alternative solution for those circumstances. Nevertheless, its merits also warrant a lot of consideration before moving to the next solution or possibly trying to augment it with other approaches.

e) Predetermined stakeholder requirements

The initiating process group in TPM (PMBOK) emphasise the need for documenting business needs/requirements before starting the project and by so doing it promotes the predetermination of stakeholder requirements (Leybourne,2009; Cadle and Yeates, 2008; Hass, 2007) which is not always the case with other project management approaches (Schuh, 2005). It has been criticised for making the scope statement acts as mechanistic point of reference for any changes that are to be formally accepted (Geraldi, 2008; Rodrigues and Bowers, 1996). Thus TPM emphasises that changes can be stabilised or minimised during the initial stages of a project (Alleman, 2008; Conforto and Amaral, 2008) which in reality might not be possible (Steffens et al, 2007; Cicmil et al, 2006). According to Aguanno (2004) this results in a locking down of requirements to form a baseline for the project which can have a retrogressive effect if the environment changes. The difficulty of this approach to project management is exacerbated when customers are not able to clearly elaborate on their requirements (Cadle and Yeates, 2008) and thus making the scope as well as the possible solution vague (Atkinson et al, 2006). While there are a number of arguments against the predetermination of stakeholder requirements, there are also some positive aspects associated with it, for example Papke-Shields et al (2009) opines that it is essential for reducing scope creep. It can also be argued that it helps with the drafting of contracts, reduces risks associated with gold creep and it gives management a challenge to put extra effort to understand the client’s requirement. Furthermore, in an effort to support the predetermination of stakeholder requirements, Chatzoglou and Macaulay (1997) argue that there is a need for including human factors (i.e. team members’ attitude, client’s attitude, project management and project characteristics) in project management, but what is notable here is that all these still lack an important component of unpredictability in project behaviour which can be a challenge in some situations.