Abstract
“Palm Theory” suggests the measure of the project management style qualitatively (Subjective) on the basis of a Baseline TART. This is seemingly important for successes to be attributed to a project is rated by the responses of the end user. When the user is unhappy with the performance of the system and its quality, it becomes difficult for the project to see success because the activity cannot be carried out on time, with quality and within budget.
Introduction
The Software Development Life Cycle (SDLC) over the years has puzzled many a project development team. The SDLC being an important aspect of any project, sad to say is fully technical oriented. As complexities of the projects increase effective management of project becomes increasingly necessary, SDLC needs to have an extended arm - that which incorporates a management ladder. This is briefly explained using “Palm Theory”.
Palm Theory
The Palm Theory is an extension to the SDLC, in providing a new phase defined “Management Styles” to hold the technicalities of the four technical phases of SDLC. This was proved & justified by adding the core of the palm theory – defined “TART” which remained as a baseline for implementing or rather performing the balancing act.
Each level of management should understand that the success of a software project is attributed not only to the technical capabilities the software can perform but also in executing or rather completing a software project within budget, time, quality and achievement of goals. This clearly reaffirms the need for management to imply it's reasoning within each stage of software development activity. Hence a combination of “Management styles” ensures that the software built is indeed robust and also the process involved during its development culminated to the defined objectives during its development.
The Palm Theory ensures that the Software Projects maintain and reassure quality of project within time and budget. The four conventional phases of SDLC thus requires a fifth behavioural phase – defined as “Management Styles” to integrate the existing phases so as to achieve the desired outcome. The following (Exhibit 1) describes the shift from the existing curvature of the previously displayed software development life cycle to the newly refined process inceptions involved to the existing line with the “‘Palm Theory’”.
Exhibit 1
The “‘Palm Theory’” represents the right palm with each finger remaining within the co-ordinates of x and y-axis. The x-axis denotes the Democratic Style of Management and the x’ axis (x in the negative direction) denotes the Autocratic Style of Management. The four fingers except thumb are visualized as technical phases of software development life cycle in their order of action in the management activity.
Phase 1: Project Definition phase is represented by the small finger.
Phase 2: The project Planning phase is represented by the ring finger.
Phase 3: Implementing the Plan is the third phase in the software development life cycle represented by the iddle finger.
Phase4: Implementation & Hand over is the fourth phase represented by the index finger.
Phase5: The new introduced phase represents a behavioral phase defined as “Management Style”. Which is always at an inclination to move from its axis of inclination to the open boundaries of the palm.
As the thumb resides within the X and Y-axis of the graph in the democratic boundaries, it is always at ease to hold an object entering the path of the Palm. But if the thumb remains at its initial inclination or goes below the inclination towards infinity of the X axis, the existing four technical phases represented by the other four finger remains the same, with no management action involved for the action becomes too democratic. On the other hand, when the thumb moves above its inclination reaching to other fingers and as long as it remains in the democratic region. The thumb finger moves with the degree of authority moving towards the other four fingers, integrating the four technical phases with the desired activity being achieved in the form of Management Style.
If the thumb finger moves from its inclination outside the boundaries of the ‘Y’ axis and moving towards the “X'” axis the activity becomes fully autocratic, producing undesirable results in the form of failures which is attributed to an extreme sense of authority implied in project management.
The ‘Palm Theory’ built on a hybrid management baseline called “‘TART’”, which emphasizes the following:
- i) Management by Task.
- ii) Management by Authority.
- iii) Management by Relationship.
- iv) Management by Technology, Tools & Techniques.
Each of the above mentioned management activity remains as the foundation on which the theories attributed to the ‘Palm Theory’ revolve around. This will impart an extra viability to the whole process of developing and implementing functionally mature software. A bounce towards developing professionally built software doesn't require structural changes in the technical aspects of the project life cycle. Visualizing the existing practices instigated me to provide the answer in the form of a theory explaining the attributes of the “Palm Theory“. This phase, will reach out as a behavioral phase proving its need right from the inception of the software project life cycle and in the long run spreading its tentacles to the existing four technical phases.
Using the baseline “TART” the open area inside the Palm describes an Open Management Style. Hence the ‘Palm Theory’ to be fully functional and inductive, the thumb (the new fifth behavioral phase) should move out of its inclination towards ‘Y’ axis and balance within the X and Y axes.
Baseline “TART” Explained
The objective of the baseline ‘TART’ is to identify quantitatively potential problems. The quantitative data should be subject to analysis and interpretations to integrate the four conventional phases of software development life cycle, using the newly introduced fifth phase called “Management Styles”, defined in the ‘Palm Theory’. Using the base line ‘TART’ we can substantiate what people intuitively know and their expectations. Base line ‘TART’ is designed in the ‘Palm Theory’ to quantitatively show the current status of an activity, program or attitude. ‘TART’ will be able to show the status of a project in a quantitative subjection from which change can be measured or balanced. ‘TART’ should be employed or measured by the project management group or the top management with an even emphasized to self measurement progressing towards evaluating the team involved and ending with the stake holder of the project.
The base line measurement applied to the management is more subjective than objective. Very few objective studies can be deployed within software project management and since objective is deployed through the art of counting, it will be considered non-argumentative. Since ‘TART’ is defined as the baseline of the fifth phase of software development life cycle in a project management style, it can be viewed as subjective because of its difficulty to measure the project management styles. “Subjective” implies that judgment is applied rather than measured.
As an additive, when we view the software development scenario, we find it difficult to count the number of hours a programmer had put into measure actual productivity. Quality productivity delivered by a programmer can be analyzed by applying the right judgment and so the process is subjective.
‘Palm Theory’ suggests the measurement of project management style quantitatively, (subjective) on the basis of baseline ‘TART’. Which is seemingly important for success to be attributed to a project is rated by the responses of the end user, when the end user is unhappy with the performance of the system and its quality, It becomes difficult for the project to see success because the activity cannot be carried out on time, with quality and within budget.
For software projects to be successful and effective from a project management standpoint, the project management should be responsive to the project management styles. The ability to explore different alternatives and seek various optima is one of the important ways of success. The success rate can be increased by the ‘Palm Theory's fifth phase management style with proper handling of baseline ‘TART’. If we lose any one dimensions of ‘TART’ the success rate decreases considerably.
The explanation of ‘TART’ is as follows
Dissociating each alphabet from the acronym ‘TART’ would give a better explanation.
Loosing out “T”, that is management by task from the acronym ‘TART’, will form the word “ART”. An art is an imagination, or the outcome of a visualization in an individual's mind. Since imaginations lack reality, losing T from the acronym ‘TART’ will see project management as an ART that can never be a reality, for we lose on the task oriented work. Every Project should have a start date and an end date with specific task, outlined to achieve the desired target. The task being outlined will have a boundary and the task without the boundary is like an artistic imagination. This will always see the project being described imaginatively with no boundaries accounted to achieve the ideas within the imagination.
For example an artist on his or her way to create an artistic marvel will be bend on a variety of ideas and the artist often keeps changing to improve his imagination to produce a better piece of work, and quiet often it is reliable and other cases unreliable. Hence there is wide degree of risk involved in producing the work. Similarly a project with no boundaries or an ever-changing boundaries is a risk. For the goal or task is lost as they change. This being the case will decrease the project success rate. Therefore it is important that so management by task should blend along with other management functionality's to achieve the desired result within a software project.
Loosing out the alphabet “A” from the acronym ‘TART’ should produce another acronym TRT', this acronym has no meaning. Since the baseline “TART” has now changed to a meaning less word or acronym, it envisages a situation where there is task, relationship, and Technology, Tools & Techniques but still has no specific end points.
For example it is like a platoon of soldiers, equipped with all modern technology and having requisite skills and targets, but without a commander who can take a decision at a right time. This can lead to a situation where there is no concrete decision making authority that can lead the troop deployment to the front lines, resulting in chaos. Another example is a book without proper binding and index. This will take the user for a ride, for he is unaware of the areas, he should scroll through to get the right information.
In the project management scenario, lack of proper authority will see a project going outside the boundaries defined because it is not structured enough to complete the task. As there is no authority, it becomes difficult to motivate the team and controlled their focus oriented tasks which ultimately can lead to a situation where the risk involved is quiet high. This shows a sharp increase in the failure rate of a project.
Loosing out the alphabet ‘R’ from the acronym ‘TART’ produces the word TAT which is defined as ‘shabby or worn’. On loosing the alphabet R from the acronym TART, the project management scenario should provide emphasis on management by task, authority and Technology, Tools & Techniques. As no formalized relationship exist within the team, the team members will more often remain as skilled robots hired to perform a specific task. In the long run the team can feel shabby and worn out from the pressure being exerted on there own by authority and gradually reaches a situation where there is no team cohesiveness.
Since the management approach is all about getting the task done by an authority, it moves to an autocratic management style. This would double the extend of authority implied. The team under pressure will be forced to move out of the project as nothing is done to boost their morale, and commitment to be part of the project.
Consider a situation in software project management, where an over extensive authority forces the performer (team member) to switch sites resulting in the project running out of hand and failing to complete on time. Therefore maintaining personalized relationship throughout the life cycle of the project with the required degree of authority stands out as the best way to achieve positive result.
Final if the alphabet T that is management by Technology, Tools & Techniques on being removed from the acronym ‘TART’ produces the word “TAR”. TAR stands for a substance, which is a by-product from petroleum refineries. It is used for road pavement. In India, it is widely used for road pavement. It is rigid in cold climate and is flexible in hot climate. Since its characteristics change according to environment it lacks the required stability to function on its own.
Envisaging this simple condition in the project management scenario we find that a decision on what Technology, Tools & Techniques is to be used with an eye on the market and customer should be first decided. During the first phase of the project itself the project management should decide what technology is to be used or how the technology has to merged to produce the right result, otherwise it can result in a similar by-product like tar which has no stability as Technology, Tools & Techniques keeps changing. Quite often it increases or tends to move out of the boundary, producing a situation where project has an ever changing dimension. This can lead to a situation where the task keeps on changing, since time and time management remain an unprecedented factor for the overall success of project. Management by Technology, Tools & Techniques should be given its due share of respect if the project is to succeed.
Process Maturity Model - “Palm pendulum Maturity model” – (PpMm)
The Palm Pendulum Maturity Model (PpMm) is adopted from the Palm Theory and is proposed as an improvising model to the waterfall and spiral models. PpMm unlike its predecessors is bound to improve the nature of project development activities in both complex as well as simple development environments. As its origin is from the Palm Theory, PpMm unlike earlier models is also a practicable behavioural (Management activity) as well as technically supportive model.
The PpMm has a set of three inter-depended life cycle processes. They are:
- a) Technical Life Cycle Process (TLCP)
- b) Supportive Life Cycle Process (SLCP)
- c) Organizational Life Cycle Process (OLCP)
As the Palm theory has already explained the lack of a management perspective in the technically oriented SDLC the preceding explanatory pages on PpMm should substantiate, the need to have management control too to integrate or bridge the gap in the technical phases.
Project failure can often be mainly attributed to – Emphasizing and revising and improving technical aspects of a project. For the technical process within a project to improve the organizational process and supportive process should form an inherent part of the whole development activity.
For example, the FormulaOne racing perspective. A combination of man, machine, management and technical capabilities. The F1 race is perhaps the best example of the tactics of management at work. A car with the best technical improvisation cannot always win, for here the team also requires a good race driver, coupled with a good supportive team, managed by a efficient and profound management vision and strategy. In the F1 scenario the team management, while the race is on, provides the skilled driver with updated processed information on track, conditions, car condition and opponent status.
Mean while the management also gets the team members to prepare for a strategy base calling (Pit stop) for the driver. Hence the tactical advantage remains within the decision making capability of the management to coordinate the activities of the skilled driver, the technically competent car and the support staff, ensuring success for the team as a whole. Certain scenarios can be visualized in a complex project development activity. Though the technicalities or the technical tools coupled with a confident supportive team – but without the role of management strategies is sure to cause the project development activity to fail.
The PpMm has its similarities with waterfall and spiral models but with improvements. Envisaging the SDLC consider the schema below:
Referencing the above schema – which resembles a pendulum - the dials within the clock are dived into four technical phases. Each phase can further be divided into ‘n’ number of Work Breakdown Structures(WBS) and mile stones set accordingly to the complexities within the project. As the model has evolved pictorially from a clock, its is evident that as with a clock having an alarm, the model too maintains provisions for setting an alarm that goes of at the point of a milestone being achieved.
A clock having two needles, with the hour needle denoting the status of the project in the particular phase is what is described in the PpMm. Meanwhile the minute needle denotes a process of Continuous Improvement (attributes of the spiral model) and Tracking and Corrective Measures within the project. At the zero hour of the clock, when both the status needle and the improvement tracking and corrective process needle coincide a project is set to Start – with clearly defined budget, task, quality and implementation cycles within the coordinates of the clock.
Meanwhile continuous task tracking, correction measures and improvements denoted by the minute needle rotates frequently throughout the various phases to track each process and task, ensuring correction. The PpMm also has its supportive life cycle process, which reside within the project Organizational Life Cycle Process (OLCP) supporting the smooth running of the Technical Life Cycle Process (TLCP). AS continuous task tracking, correction measures and improvement progresses the Supportive Life Cycle Process (SLCP) ensures improvements are made as and when required. Meanwhile the status needle will decipiate the correct project standing or the current project status. For both status indicator and continuous task tracking, correction measures and improvement needle to move further within the boundaries of a phase does require Supportive Life Cycle Process (SLCP). The Supportive Life Cycle Process (SLCP) includes a variety of attributes like:
- a) Software Project Management(SPM)
- b) Software Configuration Management(SCM)
- c) Software Quality Management(SQM)
- d) Software Verification & Validation Management(SVV)
- e) Software Documentation Management(SDM)
- f) Software Risk Management(SRM)
The above attributes remain as supportive coordinates of the technical phases of Technical Life Cycle Process (TLCP), ensuring smooth and effective progress throughout.
Unlike other models these model attributes within the PpMm contribute in its own functionality's right from start of the project till its successful completion (i.e. All attributes are an on going processes from the start till end during SDLC). PpMm also has supportive process to cater to the behavioural management style following its base line “TART”. This would remain as a behavioural bar for reasoning ‘TART’ stands for :
- a) Management by Task
- b) Management by Authority (decision making)
- c) Management by Relationship (emphasis to personalized relationship)
- d) Management by Technology, Tools & Technique.
Within this schema of PpMm model for the clock to work properly its pendulum should move well within its boundaries. Thus ‘TART’ is envisaged as the bar of the pendulum which remains as the connecting factor.
All supportive attributes remain within the ball of the pendulum. PpMm states or rather visualizes the pendulum ball as a compass having a directional needle pointing towards two opposite coordinates (e.g. N to S). On the project initializing this directional needle is set to focus towards a project goal. The directional needle when residing within the longitudinal lines of a compass denote quality management. At the same time all other attributes of the supportive system is indicated across the latitudinal lines. An intersection of the latitudinal and longitudinal lines is set as a check point for the success rate of a supportive processes. As the ball of the pendulum resides or has its boundaries defined by the baseline ‘TART’, when in motion or as it swing's or moves closer either to Autocratic or Democratic management style brings out a need to balance the direction of the needle within the compass. In the event of the pendulum loosing its balance or entering a state of abrupt stop, the directional needle is inversely effected.
Based on the above assumptions it is clear that the Supportive Life Cycle Process (SLCP) are a must for any software development life cycle. This would ensure that the continuous task tracking, correction measures and improvement process needle of the clock on reverting back with errors, supportive processes remain in charge helping initiating necessary action rectify or improve the technical process efficiency.
Within the PpMm both the Technical Life Cycle Process (TLCP) and Supportive Life Cycle Process(SLCP) resides in the Organizational Life Cycle Process(OLCP). Organizational Life Cycle Process (OLCP) includes:
- a) Organizational Management(OM)
- b) Organizational Behaviour (OB)
- c) Organizational Environment(OE)
- d) Organizational Improvement(OI)
- e) Organizational Training(OT)
These five coordinates remain directly proportional to Supportive Life Cycle Process (SLCP). On the Organizational Life Cycle Process (OLCP) having an adverse effect, the effect is further pronounced towards the Supportive Life Cycle Process (SLCP) which would invariably effect the Technical Life Cycle Process (TLCP).
The Balancing Equation:
The above balancing equation is derived from the PpMm.
The equation states that a System Development Life Cycle(i.e. SDLC) is a combination of Technical Life Cycle Process(TLCP), Supportive Life Cycle Process(SLCP), Organizational Life Cycle Process(OLCP). In the above equation the arrow denotes the magnitude of each life cycle process. It denotes that each life cycle process has a stating point and moves towards unidirectional (i.e. aiming to the success of project goal).
For example, consider a family of four, each member within the family is interdependent, but dependencies is more prone from the children to parents. If the father within the family remains as an example by setting standards, strategies and providing the environment to the family, the supportive mother upholds the children during their carrier development effectively.
On the other hand if the father remains a hindrance to the environment within the family then the supportive mother and children tend to loose their balance and the whole family structure collapses. But if the children remain as the hindrance of the smooth functioning of the family, the parents bestowed with authority and ensures that corrective action is initiated and the children are led to the right path.
In the event of Organizational Life Cycle Process(OLCP) being inefficient, it adversely effects the Supportive Life Cycle Process(SLCP) failure.
On the other hand if the Technical Life Cycle Process(TLCP) is bound by a problem, it wouldn't effect either the Organizational Life Cycle Process(OLCP) or the Supportive Life Cycle Process(SLCP) in-depth. This is because the Organizational Life Cycle Process(OLCP) or the Supportive Life Cycle Process(SLCP) provided support would rectify or rather have corrective measures being applied time and again to ensure that the Technical Life Cycle Process(TLCP) doesn't fail.
This draws a condition that for an SDLC to be effective it should be a combination of Technical Life Cycle Process(TLCP), Supportive Life Cycle Process(SLCP), Organizational Life Cycle Process(OLCP). Hence the equation stands justified.
Conclusion
A software project is an undertaking to meet established goals within cost, schedule and quality objectives. The project management brings together and optimizes resources necessary to complete the project successfully. The resources include skills, talents and co-operative efforts of a team of people, facilities, tools and equipment's information systems & techniques, money etc. Here optimization ie. Management of resources means, it is a behavioural aspect “The way of management style used to optimize the resource”. Hence the proper management style is the key factor of a successful project.
The palm Pendulum model being now introduced to eliminate the lack of a proper understanding within software developing organizations, should now be accepted as part of the software development life cycle. Having enlisted the drawbacks within the project management scenario, it is necessary to practice the approach of implementing management styles described in the palm model, to ensure that project did not tend to fail of increase in their budgetary requirement. Being a management concept palm pendulum model can increase the way management response to a task that resources and task related activities. With a high sense of confidence I can profoundly say that the palm model and Palm Pendulum Maturity Model(PpMm) will help in laying off the discrepancies involved in the project management arena.