TASK MANAGEMENT

 

  • SPECIFYING THE TASK
    • Case Example: Software Development
      • Tasks: The Process’s Variety with Type of Organization
    • The Tasks: Component and Attribute
      • Technical Issue
      • Non-Technical Issue
    • Case Example: TMCA, Projo-IMS Development Project
      • Failure of the Project
  • PLANNING THE TASK
    • Typical Tasks in Software Development Project
      • Projo-IMS Development: The Resources and Time
    • Analysis, Dissection and Planning to the Tasks
    • Summary to the Project Plan
      • Potential problems and Pitfalls
      • Risk Management
  • LEADERSHIP AND MANAGEMENT
    • Leadership and Management
    • Motivation
      • Maslow and The ‘Hierarchy of Needs’ Theory
      • McGregor and Theories X and Y
      • Herzberg’s Two-Factor Theory
    • Managerial Approach to Motivation Theory
  • MENTORING AND COACHING
    • Mentoring and Coaching
      • Behavior of Mentoring
      • Behavior of Coaching
    • Functionality to ‘Organizational Change’
  • COMMUNICATION
    • Basic Nature of Communication and Process
    • Barriers to Communication
    • Appendix: Enhancing Communication Skills

REFERENCES

 

·         SECTION 1         SPECIFYING THE TASK

1.1       Case Example: The Software Development

 

The objectives of introduction to software development in the industry is simply to explore how different types of organizations typically have differing objectives, diverging and differentiate of it bring up different ways of manipulation to the attribute for discussion and research into the Task Management study, domain to specifying those component and constraints to the attribute may vary with the objectives. Intention of the author is to illustrate the study of Task Management over the Software Development Process; the case example as well.

 

Software is widely used in helping the organization process from manufacturing industry to retail, school and universities, health care, finance and government; many individual use software for entertainment and education. The management, specification, development, and engineering are the component of this software system to buildup of the discipline and process of software development and engineering.

 

Pressman (1997) have a sensational statement as his perception to the development tenor of the software industry; mention that “software industry has been overcome with many obstacle tenor and many accomplishments, the tenor through maturity for the industry still remain with many significant work yet to do. Today, software industry is recognized as a legitimate discipline, one worthy of serious research, conscientious study. Software process models have been adopted successfully across a broad spectrum of industry applications. Managers and practitioners alike recognize the need for a more disciplined approach to software development and engineering. But many problems still remain in the industry, many individuals and companies still develop software haphazardly, unaware of modern framework and process methods of development, the quality of the software produce suffers. Debate and controversy about the true nature of the software process approach continue. Attitudes of the practitioners have changed, software progress has been made, but much remains to be done before the discipline reaches full maturity.”

 

 

1.1.1    Tasks: The Variety with Type of Organization

Haphazard process on software development is exists in the local software industry ubiquity, notice by the author; further study into this ‘haphazard phenomenon’, and opinion that this phenomenon reflecting the size of an organization and the development culture. The author gained further identification of this ‘haphazard phenomenon’ with his recent reading into the discussion of Bogue (2004) during his preparation for discuss into various software development roles. Bogue recognize that the team (the author recognizes it as tasks) dynamics are very different across of organization such as corporate developers, software company developers, and consulting developers, the author summarize Bogue discussion into table as Table 1-A:

Corporate Development
As insurance companies, manufacturing companies, or healthcare companies, categorize as corporate development. Bogue segregates the corporate development into two:

·         Large organization with structure and processes,

The development process is more defined, problem with more system in production and more production to support, the large processing of help desk support route to developer for investigation and resolution, it created a great deal of distraction, which is disadvantage for software development. Without market pressures from the IT world, corporate development shows more bureaucracy than other types of organization.

·         Small organization who are trying to develop software with limited resources.

Typically the small organization development has shown very little support of the process from more senior staff or no routinely enforced software development practices. The ways that this organization shows up is in the lack of clearly defined requirement.

Software Development Company
Longer process of decision making with the situation of the technology is perceived to be the key value of the organization contributes. Requirement at a software development company are some of the most rigid to be found in any type of software development. There’s generally more focus on having the right people to perform the roles (tasks) needed for successful software development, this is vary with corporate development where project management control is generally higher than corporate development. Challenges for a software development company are that the processes, procedures, technologies, and techniques are generally more ingrained.
Consulting Company Development
Typically, a well organize consulting company will gather good requirements and will maintain appropriate tasks management control on the project. Consulting companies focus on meeting the requirements as almost exclusion of all other factors, performance and reliability objectives in the software development are constrained to the level at which the client is willing to pay. As results such constrain are only approached to the point where they meet the criteria established in the contract or requirements. A consulting company development project stops once the minimally acceptable level has been reached.

The author notices that bureaucracy culture in large organization created redundant tasks in the software development process, this is indirect conflict with the situations which cause the process to be ineffective and require more work to get the same set of deliverables accomplished. Contrary, limitation resources for small organization occur with task overloading and multitasking to the staff; manager does programming as well. Obviously the exercise of Task Management technique may tackle by difference angle of expectation.

 

Previous experience from the author, servicing as a Software Engineering in a consulting company, he realized that a consulting organizations have the flexible to integrate with the software development practices of a wide variety of organizations; they tend to be much more progressive to adapting new software development practices into particular organization’s development process. How some of those goals may be detrimental to the software development process? Any direct impact to the tasks designed in the software development process? Weak managerial to the software development may consequent with ambiguity to the performance of the task or might it simply reaches the level of acceptable point where the individual who performing the tasks do not have the aggressive attitude to make self-improvement. If a weak managerial to tasks processes in software development, the end product will be suffer. In a brief essay by Margaret Davis in his 1995 study comments on the duality of product and process:

About every ten years give or take five, the software community redefines “the problem” by shifting its focus from product issues to process issues. Thus, we have embraced structured programming languages (product) followed by structured analysis methods (process) followed by data encapsulation (product) followed by the current emphasis on the Software Engineering Institute’s Software Development Capability Maturity Model (process). While the natural tendency of a pendulum is to come to rest at a point mid-way between two extremes, the software community’s focus constantly shifts because new force is applied when the last swing fails. These swings are harmful in and of themselves because they confuse the average software practitioner by radically changing what it means to perform the job, let alone perform it well. The swings also do not solve “the problem”, for they are doomed to fail as long as product and process are treated as forming a dichotomy instead of a duality. (Davis 1995, p.17-18, quoted in Pressman 1997)

 

 

 

Sadly, software was often little more than an afterthought (Pressman 1997). Within the software development progress, managers and practitioners have always asked for the following question, and in fact those questions implicate the critical attribute or component of Task Management:

  • Why does it take so long to get programs finished? (Timeframe)
    • When it will accomplish? (Timescale overrun)
  • Why are costs so high? (Cost)
    • Why we need more resources to accomplish? (Budget overrun)
  • Why can’t we find all errors before deliver the software? (Quality)
    • Why there are many feedbacks with redesign? (Poor Quality)
  • Why do we have difficulty in measuring progress? (Content)
    • Can we adopt others software development practices? (Technique)

 

There are many others question to be ask, where the question leading practitioners delve into the method for better maturity of software management controls. The software institute and related discipline organization such as IEEE, SEI, NASA, AMC, etc, is contributing and share their effort in development of software development management to consolidate the software industry’s practitioners, continuously introduce better maturity of development process model and framework. Let many more to practice it and continuously contribute to the industry.

1.2       The Task: Component and its Attribute.

 

With the study and discussion from case example with Software Development process, the author percept that the activities for practitioners to overcome those remain problem shall winding around the effort to improve the method of metrical measurement and Tasks to those ambiguous components of the software development process. The expectation of better maturity of software development process shall come along with this effort, as it is been continuously discussing upon the ‘Quantifiable’ to software development process.

 

Those metrical measurements are implied and compass within every detail of the software development. Tasks, a piece of work to be done (Oxford 1997), a proper management upon Tasks and quantification to it is one of the key element to achieve the big picture of a project; the completion of the series of tasks will be the main concern to the objective. It is included the goals and objectives of a project, the nature of its inputs and outputs, and work to be carried out during processing the project (Anon. 2004 author’s note). Task is the basic element of the overall process; a project is constituted by a series of Tasks. Managing and planning tasks in a project, managerial capture and show understanding the consequential attribute of it will be the key requirement to deploy tasks toward the tenor achieving the goal of a project.

That attribute of task for software development process could be encompassing within the activity such as “Requirement study”, “Quality Assurance”, “Development of Code”, “Debug and Testing”, etc; generically it is demonstrated within wide range of software industry practice. The discussion to the attribute of tasks will surrounding with both internal (technical issue) and external (non-technical) attribute. Research and experience from the author, categorize the technical issue (internal) and non-technical issue (external), the component attribute as well.

1.2.1    Technical Issue

Definition, Dependency, Decomposition, Cost, Timescale, Quality, Constraint;

Where those technical issues are surrounding with the quantifiable component, constraint might not quantifiable as it is a form of situation, but those quantifiable components incur the form of constraint. Such technical issue is the measurement that is enable for managerial to manipulate upon the adjustment, design, estimate the infrastructure how is the project to constitute. Selected few critical attribute for discussion from the study of the author:

  • Definition;

What need to be done, the content as well, to initiate and describe the task, endorse the task play a role in the process. Task is intangibly if we didn’t give it a proper definition or statement, the people who are assigned with an ambiguous task, he/she may perform without scope and guideline, without a definition and descriptions of it, it is not assignable. Definition of task can be presented by using “Work Order” or “Statement of Work”. An implicit task arise the second-order attribute if the definition has an imperfect forecast. For instance, a task to send a tank you card to the client, but the person do not know the address, so an implied task to find out the client’s address; included are unknowns that may not be known until the task is done.

 

A weak definition of Task may produce suffer to end up the project. Software development project (others project as well) constituted by a series of task, despite any relation or discrete of tasks or sub-task, once any part of the task is not properly define it may arise the chain reaction to distort every of the subsequent tasks.

  • Dependencies;

Multiple tasks in a project having it interrelationship, conjunction with other tasks or sub-tasks can be clearly illustrated by the form in Gantt charts to address it dependency. The conjunction between a series of tasks is having the indication of “End to Start”, “Start to Start”, etc, illustrated Table 1-A shown the pattern and example of task dependency analyst in critical path analysis.

Task dependency Example Description
Finish-to-start (FS) Task (B) cannot start until task (A) finishes. For example, if you have two tasks, “Construct fence” and “Paint fence,” “Paint fence” can’t start until “Construct fence” finishes. This is the most common type of dependency.
Start-to-start (SS) Task (B) cannot start until task (A) starts. For example, if you have two tasks, “Pour foundation” and “Level concrete,” “Level concrete” can’t begin until “Pour foundation” begins.
Finish-to-finish (FF) Task (B) cannot finish until task (A) finishes. For example, if you have two tasks, “Add wiring” and “Inspect electrical,” “Inspect electrical” can’t finish until “Add wiring” finishes.
Start-to-finish (SF) Task (B) cannot finish until task (A) starts. This dependency type can be used for just-in-time scheduling up to a milestone or the project finish date to minimize the risk of a task finishing late if its dependent tasks slip. If a related task needs to finish before the milestone or project finish date, but it doesn’t matter exactly when and you don’t want a late finish to affect the just-in-time task, you can create an SF dependency between the task you want scheduled just in time (the predecessor) and its related task (the successor).

Source: Microsoft Project 2003, Online Help Document.

Table 1-A: Critical Path Analysis/Method

 

For software development process, tasks example “Develop Functional Specification” and “Development of Prototype” having the dependency of “Finish to Start”, an Analyst Programmer have to complete the functional specification documentation before the Software Engineer to develop the prototype based on the specification.

  • Constraints;

Task are captured and intersected with large number of constraints, it involves many variables to the tasks interoperability, and those are determining how the tasks to be carry out and how it implements with other sub-tasks. Constraints are implicit of “Cost”, “Time”, and “Resources”. Project manager design and controls the tasks with predefine parameter, person who carry the task should demonstrate his/her skill by undertake within the constraints. Table 1-B shown the type of constraint directly impacted by “Time” within the project process.

Constraint Type Impact Description
As Soon As Possible (ASAP) Flexible With this constraint, Project schedules the task as early as it can, given other scheduling parameters. No additional date restrictions are put on the task. This is the default constraint for newly created tasks in projects scheduled from the start date.
As Late As Possible (ALAP) Flexible With this constraint, Project schedules the task as late as it can, given other scheduling parameters. No additional date restrictions are put on the task. This is the default constraint for newly created tasks in projects scheduled from the finish date.
Finish No Later Than (FNLT) Moderate This constraint indicates the latest possible date that you want this task to be completed. It can be finish on or before the specified date. A predecessor won’t be able to push a successor task with an FNLT constraint past the constraint date. For scheduled from the finish date, this constraint is applied when you enter a finish date for a task.
Start No Later Than (SNLT) Moderate This constraint indicates the latest possible date that you want this task to begin. The task can be start on or before the specified date. A predecessor won’t be able to push a successor task with an SNLT constraint past the constraint date. For projects scheduled from the finish date, this is applied when you enter a start date for a task.
Finish No Earlier Than (FNET) Moderate This constraint indicates the earliest possible date that you want this task to be completed. The task cannot be scheduled to finish any time before the specified date. For projects scheduled from the start date, this constraint is applied when you enter a finish date for a task.
Start No Earlier Than (SNET) Moderate This constraint indicates the earliest possible date that you want this task to begin. The task cannot be scheduled to start any time before the specified date. For projects scheduled from the start date, this constraint is applied when you enter a start date for a task.
Must Start On (MSO) Inflexible This constraint indicates the exact date on which a task must be scheduled to begin. Other scheduling parameters such as task dependencies lead or lag time, resource leveling, and delay can’t affect scheduling the task unless this requirement is met.
Must Finish On (MFO) Inflexible This constraint indicates the exact date on which a task must be scheduled to be completed. Other scheduling parameters such as task dependencies lead or lag time, resource leveling, and delay can’t affect scheduling the task unless this requirement is met.

Source: Microsoft Project 2003, Online Help Document.

Table 1-B: Type of Constraint

Essentially, constraints incur the side effect of “priority”, integrating into the type of constraints it is can represented as “Normal”, “High”, and “Low”.

 

 

 

 

  • Resources;

Such as tools, time, budget that a task uses or require by a task. People who carry out the task are considered as human resource. Resources are the entity of “Constraint”, status of the “Resources” constituting the measurement of “Constraint”.

  • Metrics;

Generally what it means the indication to have completed a task. It could be as simple as “Done”, “In Progress”, or “Pending”.

  • Time;

It implied with the “Resources”, it is simple but not so simple a matter in this world. Some time is discrete (One after another), some time is relative (Planting), some time is recurrence (Maintenance), and some time is absolute (Taxes). All about that is when you get into different angle of representation of Time.

1.2.2    Non-Technical Issue

Communication, Conflict, Commitment, Risk, Contingency, Disaster; basically that issue for non-technical component is the parts that is unquantifiable, but that is able for managerial to forecast by conducting consequential evaluation. Those parts come along with Risk Management, Contingency Plan, Disaster Recovery, etc.

  • Communication;

It is difficult to consider the process of interpersonal perception without commenting on how people communicate (Mullins 2002). Communication, an unquantifiable component in Task Management, although we can record and document the number of time of our communication such as email, meeting minute, teleconference, etc, in the process of the project, but that records would not the measurement to represent the criteria of a “success communication”. Essentially setting up and configure a well organize reporting framework should be the prior consideration for managerial.

  • Conflict;

Mullins (2002) describe that, Conflict is present where there is an incompatibility of goals arising from opposing behaviours at the individual, group or organizational level. Particularly, conflict is behaviour intended to obstruct the achievement of some other person’s goals. Numbers of conflict doesn’t represent the criteria of a failure projects; does managerial wish to see that any “conflict” occur within the project? “Conflict” is ponderous issue between human interpersonal, is unavoidable, “avoidance” is to reduce. Yet, conflict is not necessarily a bad thing, however. Properly managed, it can arguably have potentially positive outcomes. Such as better ideas produced, people forced to search for new approaches, clarification of individual views, etc.

 

The author have spend scads of time to study varies software development models; those are recommended approach from SEI to ACM, NASA to IEEE, Microsoft Framework to SUN Blue Print. Summary to those models are awareness to clear definition of activities and objective to the projects.

 

1.3       Case Example: TMCA, Projo-IMS Development Project

 

Digital Cube Sdn. Bhd. (DCUBE) was developed an end-to-end software solution to TMC & Associates Sdn. Bhd. (TMCA) a chartered Architect firm, for its project name Projo-IMS (Project Orientation’s Information Management System.). The development of the software system solution required to integrate TMCA current business environment to contemporary database structure with client-server framework. Previously the business process flow was implementing with the filing structural system by using Microsoft Excel, relation of process data is constructed by the functional linkage, Excel formulation, and VBA coding; it is previously serving the fundamental information flow for TMCA managerial to streamline the business process. TMCA realized the difficulty to maintain this infrastructure of information distributed model. An upgrade exercise to the file server incur the vulnerability of the filing system, TMCA structural filing system was totally collapsed after the upgrade and restructuring exercise.

 

TMCA, a chartered architecture firm, offering integration planning, design and project management services for the built environment. Project base and service oriented is the generic characteristic for an architecture firm, the major analysis and consideration to develop a software system for an architecture firm was scope to streamlining the initiation of a project through the termination of it.

 

DCUBE, an infancy software company, start up with offering custom software system development services to their clients. DCUBE embracing Microsoft Framework as their core technology for TMCA, and is the fifth project conducted by DCUBE. Currently the company is still in the development status to trial and error upon projects to expose variety discipline of software development process model.

 

A schematic requirement overview to the project is attached at page 12, Figure 1-C.

 

Schematic Overview to TMCA system requirement

1.3.1    Failure of the Project

Initially DCUBE was bringing up the development process and activities smoothly, three month after the peaceful, conflict within the understanding of functional requirement was gradually emerging on the meeting one after another. The author conducted a general meeting with the team member to find out the consequent suffered from the conflict, summarized that the quarrel was arise from the part of “Requirement Study” was not properly conducted by this it consequence with a series of conflict,

  • team member began to shift off the responsibility;
  • manager use the ambiguous requirement document as a pretext to extend the timescale;
  • engineer try to patch the functional module with unclear contingency specification and of course, make short shift of it;
  • client make use the situation to adding more function into the initial scope;
  • client bar the payment for previous progress.

Certain perspective by the author, Quality Assurance (QA) was not function in the process, before the module delivered to the client, further that the users did not aware that is for trial or actual delivery, and thus assume that is the final deliverable item. Tasks are clearly defined in essence upon the project plan; do the person who carrying out the task implementing through the objective? Unclear objective of the task and personal who comprehend of it has lead DCUBE fall into the circulation to remedy the relationship with TMCA by offering infinite commitment to the resolution.

 

The author has learned the “Requirement Study” in the project is the most essential component link to the sub-tasks. Project is a collection of tasks, thus, a chain reaction forms within. Nor matter the chain is push into failure from the beginning or the ending part, it will incur into infinite activities to remit from suffer. Barbara & Ralph (2002) state that all projects should:

  • Have a clearly stated goal.
  • To be “finite”, that is, having a clearly defined beginning and end.

Illegibility of Task designation and definition incur unclear authority and responsibility, interpersonal and task to carry out will consuming the ability of each others; in this circumstance effectiveness of task drop to the bottommost, frustration penetrate within the team.

·         SECTION 2         PLANNING THE TASK

2.1       Typical Tasks in Software Development Project

 

The author recognize that Microsoft Project is widely recognize as a suite of agile project management software, the software come with “Software Development” template, where project manager can utilize the template as a general framework, then mobilize with resources and time of the project.

Illustrated table list the set of tasks within the template (Table 2-A).

Scope Training
Determine project scope Develop training specifications for end users
Secure project sponsorship Develop training specifications for helpdesk support
Define preliminary resources Identify training delivery methodology
Secure core resources Develop training materials
Scope complete (Milestone) Conduct training usability study
Finalize training materials
Analysis/Software Requirements Develop training delivery mechanism
Conduct needs analysis Training materials complete (Milestone)
Draft preliminary software specifications
Develop preliminary budget Documentation
Review software specifications/budget with team Develop Help specification
Incorporate feedback on software specifications Develop Help system
Develop delivery timeline Review Help documentation
Obtain approvals to proceed (concept, timeline, budget) Incorporate Help documentation feedback
Secure required resources Develop user manuals specifications
Analysis complete (Milestone) Develop user manuals
Review all user documentation
Design Incorporate user documentation feedback
Review preliminary software specifications Documentation complete (Milestone)
Develop functional specifications
Develop prototype based on functional specifications Pilot
Review functional specifications Identify test group
Incorporate feedback into functional specifications Develop software delivery mechanism
Obtain approval to proceed Install/deploy software
Design complete (Milestone) Obtain user feedback
Evaluate testing information
Development Pilot complete (Milestone)
Review functional specifications
Identify modular/tiered design parameters Deployment
Assign development staff Determine final deployment strategy
Develop code Develop deployment methodology
Developer testing (primary debugging) Secure deployment resources
Development complete (Milestone) Train support staff
Deploy software
Testing Deployment complete (Milestone)
Develop unit test plans using product specifications
Develop integration test plans using product specifications Post Implementation Review
Unit Testing Document lessons learned
Review modular code Distribute to team members
Test component modules to product specifications Create software maintenance team
Identify anomalies to product specifications Post implementation review complete
Modify code Software development template complete (Milestone)
Re-test modified code
Unit testing complete (Milestone)
Integration Testing
Test module integration
Identify anomalies to specifications
Modify code
Re-test modified code
Integration testing complete (Milestone)

Source: Microsoft Project 2003, Software Development Template.

Table 2-A: Generic software development framework

 

The author is utilizing the framework (Table 2-A) as a foundation to develop a project plan upon the engineering development activities for the case example of Projo-IMS Development Project.

2.1.1    Projo-IMS Development: The Resources and Time

Projo-IMS development project have given a six month time frame for delivery. The project team is organized as Figure 2-B.

Source: DCUBE Sdn Bhd, 2002, “Proposal for TMCA Projo-IMS Development”.

Figure 2-B: Project Organization Chart.

 

For this project planning to the case example, the author is demonstrating the project planning study within the section of software engineering activities as at:

  • Design
  • Programming
  • QA Testing
  • Documentation

 

2.2       Analysis, Dissection, and Planning to the Tasks

 

There are nine programs to develop in the project. The author conducted the simple analysis through a project planning practice (reproduce and planning guide from Bocij et al. 2003) by dissection each of the task and program to a different level of difficulty to organize the planning matrices. The first step is to estimate the difficulty level of each item of the programs, as Table 2-C:

 

Program Name Difficulty Level
· Project Enquiry Moderate
· Project Register Moderate
· Progress Report Moderate
· Timesheet (Project Cost and Leave) Difficult
· Billing (Request for Payment) Difficult
· Client and Employee Profile Easy
· Payment Collection Moderate
· Account Receivable Difficult
· Reporting Difficult

 

Table 2-C: Assessment to difficulty of deliverable item.

 

For each program’s difficulty level, justify the effort day (duration) of task to be carrying out by Design, Programming, QA testing, and Documentation, as Table 2-D:

Activities/Tasks Effort (by man days)
Easy programs Moderate programs Difficult programs
· Design 1 2 5
· Programming 1 3 7
· QA Testing 2 3 3
· Documentation 1 2 2

 

Table 2-D: Assessment to effort of man days.

 

 

With the parameter result between Table 2-C and Table 2-D, combine both table as Table 2-E, then the relation and total effort is clearly stated

Program Name Difficulty Task Effort Total Duration
· Project Enquiry Moderate Design 2 10
Programming 3
QA Testing 3
Documentation 2
· Project Register Moderate Design 2 10
Programming 3
QA Testing 3
Documentation 2
·  

Progress Report

 

Moderate Design 2 10
Programming 3
QA Testing 3
Documentation 2
·  

Timesheet

 

Difficult Design 5 17
Programming 7
QA Testing 3
Documentation 2
· Billing Difficult Design 5 17
Programming 7
QA Testing 3
Documentation 2
· Client and Employee Profile Easy Design 1 5
Programming 1
QA Testing 2
Documentation 1
· Payment Collection Moderate Design 2 10
Programming 3
QA Testing 3
Documentation 2
· Account Receivable Difficult Design 5 17
Programming 7
QA Testing 3
Documentation 2
· Reporting Difficult Design 5 17
Programming 7
QA Testing 3
Documentation 2
Total man days required for development and engineering 113 days

 

Table 2-E: Estimated total effort for development tasks

The author hypotheses the man power resources availability to the development team members as eight (8) hours per day and five (5) working days per week, two parameter for resources planning come with:

  • Work rate – this describes the speed at which the resource works (i.e. a work rate of 1.0 means that a task scheduled to take one day should only take one day to complete satisfactorily; a work rate of 1.5 means that a task scheduled for three days should only take two days etc.) (Bocij et al. 2003)
  • Availability – Each resource will be available for certain amounts of time during the week. 100% availability = 5 days per week, 50% availability = 2.5 days per week, etc. (Bocij et al. 2003)

The key approach by the author is to developing a project plan that meets the criteria as:

  1. Approximately half of the man day’s duration (56.5 days) to the calendar day.
  2. Limit the man power resources within availability, as, no over locate with overtime.

Parameter for resources availability as Table 2-F:

 

Resources Work rate Availability
· Project Manager 1.0 100%
· Technical Manager 1.0 100%
· System Analyst 1.0 100%
· Software Engineer 1 1.0 100%
· Software Engineer 2 1.0 100%
· Quality Assurance 1.0 100%

 

Table 2-F: Projected resources availability

 

Availability and accuracy of a project planning vary and dependant with the stage of the project status, an initial plan need adjustment to refine after the project start, such refinement come along with the impact such as “Risk” where Risk Management is integrated. A plan that is developed at the “initiation phase” of a project is developed likely what has the author demonstrated, Bocij et al. (2003) mention that this is normally a high-level analysis that does not involve the detailed identification of the Tasks that need to occur as part of the project.

The author plots that parameter into Gantt-Chart (Page 20, Figure 2-G); demonstrate the overall planning to the engineering development’s tasks and activities.

 

Figure 2-G: Tasks planning plot with Gantt-Chart

 

2.3       Summary to the Project Plan

 

Projects and tasks planning to software have an essential description in the technical report to ‘Capability Maturity Model’ by Software Engineering Institute; the purpose of Software Project Planning is to establish reasonable plans for performing the software engineering and for managing the software project (Paulk et al. 1993). It is involves developing estimates for the work to be performed, establishing the necessary commitments, and defining the plan to perform the work (Paulk et al. 1993). Initial stage of a project planned with estimated parameter such as number of weeks, certain availability of resource to establish the big picture, theoretically every of the plan is perfect and emotionally foresee the excellent outcome. A more detailed and more accuracy project plan will be produced as the project start or as risks factor is unveil from the initial plan, while the project is in progress.

2.3.1    Potential Problems and Pitfalls

The project plan developed by the author is capture the streamlining process as:

Figure 2-H

 

Deem, by capturing and plan with the process as Figure 2-H is having the pitfall by ignorance to the recurrence of the whole process after incorporate feedback from the users if the users feedback with extra or unaware requirement during the requirement study. Then the whole recurrence process will be Figure 2-I:

 

Figure 2-I

A traditional waterfall model of system development having the recurrence prediction process for each of the activity, as Figure 2-J:

 

Source: Modified from Bocij 2003

Figure 2-J: Traditional Waterfall model

 

The project plan developed by the author does not penetrate the practice of the waterfall model where the author experience many variations while releasing the trial program to the users, variation or change request process does not in the picture where the plan might incur with time frame overrun if there is any requirement change feedback from the users.

 

However, the man days required for engineering development is 113 days, by applying the resources and time planning with Gantt-Chart technique, the plan shown 25 working days of calendar date is required to develop the whole programs. As this result is because of the author override the work functionality of some of the resources, like Project Manager has been located to assist for documentation and technical writing, Technical Manager and Quality Assurance has been located to assist for coding to develop the program.

The development of the plan is for the division for engineering activities, according to the delivery time frame for the case example – Projo-IMS Development, the plan still having an approximate 25 calendar date (working day) to implement with the Change Management.

 

Despite the technical analysis to the plan, Quality pitfall enclosing the whole engineering outcome, as the author does not considered the “Quality” measurement to non-functional requirement, such as engineering to develop maintainability and reliability of the programs. If such factor considered into engineering development, deem, with the man power resources availability of the case example, the resources need to over allocate to capture the time frame.

 

2.3.2    Risk Management

Charette stated the following conceptual definition of risk in his study, the author summarize as (Charette 1989, quoted in Pressman 1997, p.132):

  1. Risk concerns future happenings. Today and yesterday are beyond active concern, as we are already reaping what was previously sowed by our past actions. Therefore, by changing our actions today, create an opportunity for a different and hopefully better situation for ourselves tomorrow.
  2. Risk involves change, such as in changes of mind, opinion, actions, or places.
  3. Risk involves choice, and the uncertainty that choice itself entails. Thus paradoxically, risk, like death and taxes, is one of the few certainties of life.

 

Three of the conceptual underpinnings are always in evidence. The author identifies three of the risk presented by Charette into the case example: software development project.

  1. When risk is considered in the consequent process of software development, “Change” or “Variation” always is the key element to distort the objective and overrun the budget. Thus, “Change” is a factor of “Risk” within software development process.
  2. Documentation is recording the event, the actions, and problems resolution in the project, documentation remind and share the success and failure references, good documentation should recommend and suggest the best practice. Frivolous documentation absence the prevention, less caution to the next project and new development crews.
  3. Stakeholder, they always have a “Choice”, while choosing the suitable developer or vendor. When considered into technology for development option, developers always have a “Choice”.

 

Others assessable risk in software development project is identified by Sommerville (2001) in his software engineering study and listed the possible software risks, as Table 2-K:

Risk Risk type Description
Staff turnover Project Experienced staff will leave the project before it is finished.
Management change Project There will be a change of organizational management with different priorities.
Hardware unavailability Project Hardware which is essential for the project will not be delivered on schedule.
Requirement change Project / product There will be a large number of changes to the requirements than anticipated.
Specification delays Project / product Specifications of essential interfaces are not available on schedule.
Size underestimate Project / product The size of the system has been underestimated.
CASE tool underperformance Product CASE tools which support the project do not perform as anticipated.
Technology change Business The underlying technology on which the system is built is superseded by new technology.
Product competition Business A competitive product is marketed before the system is completed.

Source: Sommerville 2001.

Table 2-K: Possible software risks

 

Many risks in software development are universal. There is a process model to manage it. Typically risk management involves several stages:

  1. Risk identification – possible project, product, and business risks are identified
  2. Risk analysis – the likelihood and consequences of these risks are assessed.
  3. Risk planning – plans to address the risk either by avoiding it or minimizing its effects on the project are drawn up.
  4. Risk monitoring – the risk is constantly assessed and plans for risk mitigation are revised as more information about the risk becomes available.

 

Illustrate the stages listed as above into process flow, as Figure 2-L:

 

Source: Sommerville (2001)

Figure 2-L: The risk management process.

 

Further study on Risk Management to clarify the risks item that is identifiable in software development project, Pressman (1997) has created a risk item checklist:

  • Product size

Risks associated with the overall size of the software to be built or modified.

  • Business impact

Risks associated with constraints imposed by management or the marketplace.

  • Customer characteristics

Risks associated with the sophistication of the customer and the developer’s ability to communicate with the customer in a timely manner

 

  • Process definition

Risks associated with the degree to which the software process has been defined and is followed by the development organization.

  • Development environment

Risks associated with the availability and quality of the tools to be used to build the product.

  • Technology to be built

Risks associated with the complexity of the system to be built and the “newness” of the technology that is packaged by the system.

  • Staff size and experience

Risks associated with the overall technical and project experience of the software engineers who will do the work.

 

Taka an overview from a simple planning on how risks can be managed, manipulates with Table 2-M:

 

Item Risk type Occurrence rate Impact Cause Respond by Consequent to Expectation stage Prevention Recovery strategies
1 Requirement change 60% Serious User’s feedback System Analyst Risk 4 Trial release Document with variation order Nil
2 Increase of software size 30% Serious Business environment change Project Manager Risk 5 Uncertain Understand from the client, consult the consequential cause Reimbursement of time lost from the client
3 Change of team members 20% Serious Organization change Company Nil Uncertain Employment policy, increase the retain ability of staff Rapid recruitment process
4 Technical support unreachable 10% Moderate Unawareness of technology used Technical manager Risk 2 Coding Uncertain Nil
5 Budget overrun 30% Serious Development behind schedule Project Manager Risk 1

Risk 2

Risk 4

Uncertain Uncertain Nil

 

Table 2-M: Manage Risk

 

Reference and modified; Source: Deng Ziyun 2005, “Project management, methodology and strategies” (Chinese translated), Changsha Environmental Protection College, http://pm.csai.cn/all/no368.htm

 

·         SECTION 3         LEADERSHIP AND MANAGEMENT

3.1       Leadership and Management

 

While it is somehow difficulty and it is relational ambiguous to define exactly what people mean by “Good Leadership” and “Good Management” as there are many perspective with many interpretations of its meaning. Adair in 1988 study drew on etymological origins to explain the difference between ‘management’ and ‘leadership’.

“‘Leadership’ comes from an Anglo-Saxon word that means a road, a way, the path of at sea – a sense of direction. ‘Management’ is from Latin manus – a hand – and it has to do with handling a sword, a ship, a horse. It is closely linked with the idea of machines, and it gained currency in the nineteenth century in describing what entrepreneurial engineers and accountants were doing when starting and running their business.” (Adair 1988, quoted in Beech et al. 2001)

 

Taffinder (1995) suggested that everyone has a theory but, although know quite a lot about management, we do not knows as much about leadership. Handy believes that:

Like motivation, the search for the definitive solution to the leadership problem has proved to be another endless quest for the Holy Grail in organization theory. (Taffinder 1995, quoted in Mullins 2002)

 

Sir Peter Parker (1994) incisively described the matter of why academically find that ‘leadership’ is difficult to analyze exactly what it mean, the ambiguity: “Nothing in business circles brings such a rush of clichés to the head as leadership, one of those humpty-dumpty words which, as Alice said, mean whatever we want them to mean … Leadership is one of those elusive priorities, an area in which there is no absolute, and no guaranteed model. So it turns out to be not only vital but also fun to talk about what makes a leader.” (quoted in Beech et al. 2002).

 

Zaleznik (1977) defined the difference of roles between ‘manager’ and ‘leader’. Manager focus their attention and energy on the role of play in events that occur or in a decision-making process, whereas leader concentrates with ideas, and relates to others in more intuitive and empathetic ways. Manager focus on how things get done, leader focus on what the events and decision mean to people.

Bennis (1989) suggests that there are specific difference between the characteristics of management and leadership, Table 3-A (Bennis 1989, quoted in Beech et al. 2001):

Management Leadership
Administration Innovation
Copy Original
Maintenance Development
System and structure People
Rely on control Inspire trust
Short-range view Long-range view
Ask how and when Ask what and why
Eye on the bottom line Eye on the horizon
Imitate Originate
Accept the status quo Challenge the status quo
Classic good soldier type Own person type
Do things right Do the right thing

Source: Bennis 1989, from Beech et al. 2001.

Table 3-A: Characteristics of Managers vs. Leaders in the 21st Century.

 

Peters and Austin (1985) capture many of these differences view that ‘Leadership is the liberation of talent rather than restraint by rule’. A currently fashionable phrase at the time of writing is that leaders aim at ‘winning people’s hearts and minds’, however, managers aim at optimizing to utilize of ‘resources’. By merging and distinguish the ambiguity definition of leadership to the classical model of the management functions, leadership might look like Figure 3-B:

Source: Peters and Austin 1985.

Figure 3-B

 

Greenberg and Baron (1997) distinguished leadership and management from difference perspective of interpretation, illustrated as Figure 3-C:

 

Source: Greenberg and Baron 1997, Behavior in Organization.

Figure 3-C

 

Through out the study, the author captures that the definitude key to distinguish the disparity between Leadership and Management is ‘Influence’, where the leaders influence others to attain the objective and managers did not. ‘Influence’ a power affecting a person, group, or course of events, especially one that operates without any direct or apparent effort (Kingsoft 2003). In summary, Leadership and Management play several overlapping functionality in actual practice. When in this overlapping situation, most are recognizing the person who actually runs things with most influential having the leadership characteristic. “Leadership”, despite the complexity of research, it is something a sensibly differentia.

3.2       Motivation

 

Human are easily to demotivate, whereas motivating an individual somehow is difficult. Leadership is related to motivation, interpersonal behavior and the process of communication (Mullins 2002). The word ‘motivation’ comes from the Latin ‘movere’, mean to move (Beech et al. 2001). What moves people to work? Motivation is one of the key concepts in leadership management. A motivated workforce can drive an organization to attain higher standard of performance. Motivation is a broad and complex concept, but organizational scientists agree on its basic characteristics (Blau G. 1993, quoted in Greenberg & Baron 1997). Figure 3-D illustrated the basic component of Motivation.

 

Source: Modified from Greenberg & Baron 1997.

Figure 3-D: Motivation, its basic component.

 

Mullins (2002) has identified the meaning of motivation with general terms as Motivation can be the direction and persistence of action, the basic underlying question is ‘why do people do what they do’? The underlying question of motivation is some driving force within individuals by which they attempt to achieve some goal in order to fulfill some need or expectation. Figure 3-E illustrated by Mullins (2002) detailing Figure 3-D with the underlying question:

Source: Mullins 2002.

Figure 3-E: Basic motivation model.

 

3.2.1    Maslow and the ‘hierarchy of needs’ theory

The ‘modern’ assumptions about human behavior were those which underlay a theory motivation which had been presented to professional psychologists by Abraham Maslow since at least 1943. Maslow saw people as being motivated by a series of “drives” that are inherent in every human being, a set of needs which people seek to satisfy. These drivers emerge more or less in a set order. Our behavior appears to be largely unaffected by some of these needs until other more needs have already been satisfied. This ordering of human needs into a ‘hierarchy’ has appealed to both managers and management theorists and has profoundly influenced policy in the area of human resource management. To explain human motivation we have to understand how our basic instincts have become modified by our environment and culture which in turn reflect the highest capacities and unique nature of humankind. Maslow hierarchy of needs is usually displayed in the form of pyramid, this is an appropriate form of illustration as it implies a thinning out of needs as people progress up the hierarchy, as Figure 3-F:

Source: Modified and summarized from Mullins 2002.

Figure 3-F: Hierarchy of Needs

 

Maslow’s work contrasted with the conventional view of the link between job satisfaction and motivation as expressed by Taylor F.W. 1949 “now the worker wants just what they wants,’ and ‘high wages and opportunity for advancement.” (Taylor 1949, quoted in Beech et al. 2001) Wage payment is based upon paying a premium above the going rate in the district for a particular type of work when a ‘first class man’ could meet the time studied criteria of a ‘fair day’s work’. Managers who could not match Taylor’s system of tight controls and work measurement continued to rely on piece-rate earnings (payment by results) or bonuses for achieving a certain target output as the main, if not the only motivational tools. So the variation of payments by results in performance related pay schemes.

 

3.2.2    McGregor and theories X and Y

McGregor (1960) developed an organization development programs for many organizations, McGregor began his argument by pointing to the practices of American production management, based as it was upon the work measurement and scientific management principles pioneered by Frederick Taylor, McGregor claimed that ‘Observe the practices of the American manager, and you will see that he make certain assumptions about human nature’. He described and created the concept of Theory X and Theory Y. In this, McGregor classified managers’ attitudes and perceptions about the worker and the design of organizations as falling into Theory X and Theory Y.

Theory X assumptions:

  • Work is inherently distasteful; the average human being has an inherent dislike of work and will avoid it if he can.
  • The average person is lazy and unambitious; because of this human characteristic of dislike of work, most people must be coerced, controlled, directed, and threatened with punishment to get them to put forth adequate effort toward the achievement of organizational objectives.
  • Typical workers avoid responsibility; human being prefers to be directed, wishes to avoid responsible and has relatively little ambition, wants security above all.
  • The principle worker incentive is money.

 

Theory Y assumptions:

  • People enjoy work; the expenditure of physical and mental effort in work is as natural as play or rest.
  • Recognition and self-fulfillment are as important as money.
  • Man will exercise self-direction and self-control in the service of objectives to which he is committed.
  • Commitment to objectives is a function of the rewards associated with their achievement.
  • The average human being learns, under proper conditions, not only to accept but to seek responsibility.
  • Workers at all levels will exhibit creativity and ingenuity when the chance is given.

 

McGregor intentionally set out to accomplish a particular objective:

It is not important that management accept the assumptions of Theory Y … it is important that management abandon limiting assumptions like those of Theory X, so that future inventions with respect to the human side of enterprise will be more than minor changes in already obsolescent conceptions of organized human effort.

McGregor (1960, Pg 254)

McGregor contended that it was not enough merely to bribe the reluctant worker with the prospect of financial rewards. These would be gladly accepted, of course, but management would face continuing demands for yet higher rewards and there was no guarantee that rewards alone would produce the necessary effort.

3.2.3    Hertzberg’s Two-Factor Theory

Herzberg and his collaborators first reviewed the current literature on job satisfaction. They were critically of what they saw as the apparent ambiguity of much of the earlier, mainly questionnaire-based approaches to the subject. It was not always clear what people meant when they claimed to be ‘satisfied’ with their jobs not was it always clear how being ‘very satisfied’ differed from being just ‘satisfied’. They therefore developed a new method of investigating the subject. Rather than simply enquiring whether or not people were ‘satisfied’ with their jobs, the researchers asked their respondents in individual unstructured interviews to describe the times when they felt especially ‘good’, or satisfied with their jobs.

 

Employees may complain of dissatisfaction at being underpaid for the work they are required to do. But to give someone in that position a pay rise does not make that employee ‘satisfied’, or rather, more motivated to perform better. It merely stops the moaning. The opposite of ‘being dissatisfied’ claims Herzberg, is not to be ‘satisfied’ but to be ‘not dissatisfied’. This is because analysis of the critical incident suggests that much more than fair or even generous remuneration is necessary to make workers truly ‘satisfied’.

When Hertzberg’s accountants and engineers reported being satisfied they described a set of factors which included:

 

  • Obtaining a sense of achievement from the work they were doing.
  • Having a sense of responsibility or autonomy for a specific outcome or area of work.
  • Being recognized for their special efforts or aptitudes.
  • Obtaining a sense of learning or development of their skills or career.
  • Carrying out tasks which were seen as being inherently challenging, interesting or worthwhile.

 

Figure 3-G illustrated the Two-Factor Theory:

Source: Mullins 2002.

Figure 3-G: Representation of Herzberg’s Two-Factor Theory.

By contrast, when they were dissatisfied they identified quite different factors as being present which, in the view of the respondents, were to varying degrees responsibility for the dissatisfaction. The ‘dissatisfying’ factors tended to be identified as:

  • Company policy and administration
  • Relationships with superiors and colleagues
  • Technical competence of superior
  • Working conditions
  • Wages and salaries

 

Herzberg referred to hygiene factors and motivators:

  • Hygiene factors are associated with dissatisfaction because they are generally associated with conditions that surround the job
  • Motivators promote positive job satisfaction, and are factors which are inherent in the job itself.

3.3       Managerial Approach to Motivation Theory

 

Although there is some others contemporary motivation theory like, ‘McClelland’s Achievement Motivation Theory’, ‘Vroom’s Expectancy Theory’, ‘Equity Theory’. Through out the study the author deem the traditional approach as Maslow’s Theory, McGregor’s Theory, and Herzberg’s Theory captured or known as universal theories, because it is a usual approach to an understanding of human’s internal cognitive processes and related to human motivation.

 

  • Maslow: The ‘Hierarchy of Needs’ Theory and Herzberg: Two-Factor Theory

The author view similarity between Maslow’s Theory and Herzberg’s Theory. As Maslow’s Theory and Herzberg’s Theory emphasizing the human’s basic instinct – ‘needs’ and ‘satisfaction’, the author tend to believe that, managers can improve employee’s performance by linking job behaviors with the satisfaction and needs of he or her individual’s current situation needs. For example, a ‘fresh graduate’ employee needed to fulfill the ‘physiological need’ where it is essentially fulfillment from he or her paycheck. Then managers can link the job behaviors to meet this ‘physiological’ level. Progressively, managers will challenge if the ‘fresh graduate’ employee had has reach the ‘comfort zone’ in the company, thus, he or her might in the stage to expecting the job security commitment from the company. Then the managers required insight awareness toward the diversification.

 

Managers then can certainly use the understanding of Maslow’s Theory – the Hierarchy of Needs as a guide. At the same time, the challenges for manager is not only come along with the transitional change of individual needs, whereas, within the organization there is different employee with different needs, managers require to measure and balance it to create a workplace according to the context of the situation where employee feel fulfilled and willing to work productively. People are motivated to do a job well when organization fulfills them to meet one or more of their personal needs.

 

Pepitone and Bruce (1998) suggested following fulfillment according to Maslow’s theory, the author summarized as:

How to meet physiological needs at work:

  • Create a comfortable, safe, and pleasant environment for employees.
  • Show them that they don’t need to park their personalities outside the door.
  • Pay competitive salaries so that employees can comfortably provide for themselves and their families.
  • Provide greater financial opportunities for employees who want or need more money – such as overtime or other incentives.

How to meet security and safety needs at work:

  • Be consistent and fair with everyone.
  • Protect employees with safety rules and policies.
  • Take extra steps to protect workers against violent crimes by hire security.
  • Communicate information regularly.

How to meet social needs at work:

  • Give employees opportunities to work in groups and with other departments.
  • Create opportunities to help employees develop relationships and become accepted and appreciated by teammates.
  • Show your concern for team members and encourage them to do likewise.

How to meet ego-status needs at work:

  • Give positive feedback and praise on a regular basis.
  • Let people excel and move into areas of responsibility that are high-profile and that demonstrate their talents and skills.
  • Set up different levels of recognition programs based on levels of performance.
  • Ask for people’s opinions. Involve others in the planning process.
  • Always say, “Thank you”.

How to meet self-actualization needs at work:

  • Allow autonomy.
  • Give employees the freedom to be creative.
  • Treat mistakes as learning experiences.
  • Provide opportunities for more challenging work.
  • Support personal and professional growth through ongoing learning and training opportunities.

 

  • McGregor: Theory X and Theory Y

With the assumptions of Theories X and Y, the dependency is come with how is the managers’ self-realization with the theory; managers treat employees according to his or her beliefs about human nature. Pepitone and Bruce (1998) identified the outcome of management style where which assumptions are adopted:

Theory X Approach: Control-Oriented Manager-

  • Makes decisions without the input of others,
  • Maintains control,
  • Is confident in the validity of his or her views,
  • Is goal-oriented and sometimes demanding,
  • May use pressure to reach objectives,
  • May use discipline with those who don’t do the job correctly,
  • Acts decisively and can confront poor performance,
  • Expects no criticism from the team.

 

Theory Y Approach: Empowerment-Oriented Manager-

  • Makes decisions by consensus and helps others feel ownership,
  • Encourages creativity and initiative,
  • Coaches others and effectively facilitates the work of others,
  • Leads by example,
  • Gives recognition for work done well,
  • Helps people grow in their work and gain more responsibility,
  • Values and encourages teamwork.

·         SECTION 4         MENTORING AND COACHING

4.1       Mentoring and Coaching

 

Before studying into academic research for mentoring and coaching, the author find out from the dictionary for it traditional definition.

Mentor                        –           experienced and trusted adviser of an inexperienced person (Oxford                                   1997), a wise and trusted counselor or teacher (Kingsoft 2003).

Coach              –           teach or train somebody, especially for an examination or a sporting

Contest (Oxford 1997), a person who trains or directs, gives                                    instruction (Kingsoft 2003).

 

Mullins (2002) identified that mentoring and coaching is considerable confusion and having variety opinion amongst individuals. Mullins described that:

Coaching – is a process that uses deductive, or ‘drawing-out’, techniques to increase an individual’s ability and willingness in a specific subject or problem area. Ideally the techniques are used in a structured manner. The coach does not have to be an expert in the subject. (Mullins 2002)

 

McKenna and Beech (2002) described from different perspective that coaching considered as an improved version of demonstration, the process associate the ingredients such as structure, feedback, and motivation where is not presented in the ingredient of ‘demonstration’. Coaching is predominantly about showing people how to apply knowledge they already posses.

 

Mentoring – is a process that uses a mixture of inductive (‘pushing-it-in’ or telling) and deductive (‘drawing-it-out’ or coaching) techniques to increase an individual’s ability (and sometimes willingness) in a specific subject. Ideally a structured programmed is used. The mentor must be an expert in the subject. (Mullins 2002)

 

Collating to the description with Mullins, McKenna and Beech pointed out the implication of ‘the mentor must be an expert’ that the trainee (mentoree or protégé) observes the skills displayed by the mentor, and copied and adopted the skills.

Mullins (2002) identified and highlighted the similarities and differences between coaching and mentoring, the author reproduce as the comparison table as Table 4-A:

Mentoring Coaching
Uses a mixture of inductive and deductive techniques Uses deductive techniques
The mentor must be an expert in the subject The coach does not have to be an expert in the subject
The prime beneficiary is the organization but the individual also benefits The prime beneficiary is the individual but the organization also benefits
A mentoring program is measured in months A coaching session is measured in minutes
The mentor must be available almost on demand but at least on regular basis Can be an off-the-cuff session
More formal but can include informality Usually informal, but can be formal
Respect for the mentor’s knowledge of the subject is essential Respect for the coach is usual
Rapport between mentor and mentee is essential Rapport between coach and coachee helps

Source: Summarized from Mullins 2002.

Table 4-A: Comparison of Mentoring and Coaching.

 

As a coaching role, Hendricks (1996) identified that coaching is more than a set of management actions for improving performance. It is an involved and supportive approach for allowing others to realize their potential (Hendricks 1996). Further identification by Hendricks, the coaching role involves basic facilitation as:

  • Involvement and Trust
  • Affirming and Acknowledging
  • Clarifying and Verifying
  • Motivating and Inspiring

 

Markle (2000) identified that coaching is a technique for helping others reaches peak performance and ultimate potential. John Whitmore (1996) described that the essence of coaching as embracing an approach toward learning that emphasizes active employee involvement: “Coaching is unlocking a person’s potential to maximize their own performance. It is helping them to learn rather than teaching them.” (Whitmore 1996, quoted in Markle 2000)

 

Continue by studying into William Hendricks’s research into mentoring role, mentoring is reserved for managing those people whose performance is above average (Hendricks 1996). Detailing into mentoring characteristic, Dubrin (2000) described that a mentor is an individual with advanced experience and knowledge who is committed to giving support and career advice to a less experienced person. Much of the career advice centers on upward mobility. A mentor is a helper and confidante, inspires and helps another person grow (Dubrin 2000). The author extracted from the study to identify how mentoring role is involves basic facilitation to make comparison with coaching role:

  • Empowerment and Developing
  • Counseling and Teaching
  • Helping and Guiding
  • Sharing and Directing

 

Within the corporate culture, Collin (1992) mention that the recent significance of the mentoring system in a corporate culture sense has been underlined (Collin 1992, quoted in McKenna & Beech 2002); said that it provides a channel through which core organizational values and meanings are conveyed and fortified by mentors of the status of senior managers at the twilight of their careers, and absorbed by those who will eventually succeed them. The characteristics one would expect to find in a mentor are summarized in as “Characteristics of a Mentor”:

  • The relationship between the mentor and the protégé tends to be open ended with less immediate concern for attaining goals than you would expect to find in situations where a boss sets targets for subordinate. It is a protected relationship in which learning, experimentation and risk taking can occur and potential skills are developed with outcomes expressed as competencies.
  • The mentor is knowledgeable, has the ability to place issues in a broader context, helps the protégé to analyze and understand social interactions at work, and has high status and a strong power base in the organization.
  • The mentor is a good listener, able to empathize with the protégé, is able to relate well to people and establish rapport with the protégé and is willing to use their power to influence events. The mentor should avoid encouraging an over-dependent relationship and recognize the boundaries of his or her capacity to help.
  • The mentor is involved and willing to share their expertise with the protégé potential for equaling or surpassing them in status.
  • The mentor has a commitment to developing others, having a genuine interest and pleasure in the protégé achievements.
  • The mentor is willing to challenge, where appropriate, the ideas and judgments of the protégé in order to force a re-examination of the issues, and in the process is providing good feedback. Constructive criticism is just as important as encouragement.

4.2       Functionality to ‘Organizational Change’

 

In recent year change in the business environment has become a topic that is valuable for study, prevalence term ‘Organization Reengineering’ tend to be the ‘hot topic’ in organizational change. ‘Reengineering’ positioning by the technologically impact where addressed by Minor (1995), that is many companies are trying to use such tools as process mapping and the creative use of information technology to redesign their business process, reduce cycle time as well as bureaucracy, and enhance their productivity. Whatever cause the changes needed for an organization, the message for an organization is clear: “Change or Disappear”! Cook et al. (2004) drawn a planning and the preparation for organizational change; one of the key elements and shall be the first prior consideration before the implementation is “Prepare people for change”, with this consideration mentoring and coaching is also view as one of the success factor by supporting the change. Cook’s hence to make further suggestion that what can be delivered by mentoring and coaching during and after the change:

  • Provide appropriate training in new skills and develop new attitudes and behavior patterns to suite the changes.
  • Guidance to each person that he or she is accountable for some aspect of the change.
  • Provide more feedback than usual to ensure that people always know where they stand.
  • Counseling the people who need to take time to adapt the new ways and initially it is fair to expect a drop in performance after the change.
  • Avoiding dismissing those who resisting the change, help them let go of the ‘old’.
  • Monitoring the progress by give people chance to step back and look at what is going on. Ask for feedback on what is working well and what could be better.
  • Encourage people to think and act creatively, listen and act on employee suggestions.

Summarized from Cook et al. 2004

McKenna and Beech (2002) captured that mentoring and coaching can be particularly useful by generating ideas and get people involved into the management of change. Where coaching is predominantly about showing people how to apply knowledge they already possess, which this coaching’s attribute displayed the valuable function for organizational revamp. By mentoring, it can provide the invaluable insight into the politics and culture of the organization, during the change of an organization political change and cultural transformation is silently evoked, mentoring role will provide one of the key factors to the succession of transition. As a result the mentor contributes to confidence building and the career development and provides him or her with a useful informal network within the organizational change.

 

Recap from the discussion to ‘Motivation’, Maslow’s ‘Hierarchy of Needs’ Theory, the author deem the changes of ‘Needs’ of individual also a component and related to the organization change. From this consideration, the technique of mentoring and coaching will become the valuable aids to the change of ‘Needs’. While the ‘Needs’ shifting from one level to another, for example: from Physiological needs to Safety needs, the person, he or she could change with their attitude, behavior, or vision on their working position. When a person is undergoing with significant change, mentoring are necessary to adapt which five issues has been identified by Shea (2001) as:

  • A clear vision of how the his or her situation will be after the change
  • Time to absorb the new vision
  • Time to adjust behaviors
  • To manage the stress of change
  • Time to ponder the meaning of the change, and to internalize and own the change

 

After the change, organizational change or individual change, there may be some query or worriment from the employee, they may need the answered. Hereby the role as a coach displayed it characteristic. Minor (1995) described that the job of a coach is to hear these questions and assist the employee in answering them:

  • How am I doing?
  • How do others see me?
  • What is expected of me?
  • How can I best perform my current job?
  • What is this corporate culture like?
  • How can I get where I want to go from here?
  • Can I take risks here?
  • Am I being paid to think or just execute?
  • What are the rewards for working hard?
  • How can you help me realize current job satisfaction and long-term career goals?

 

 

 

 

·         SECTION 5         COMMUNICATION

5.1       Basic Nature of Communication and Process

 

Communication is the exchange of thought, messages, or information; as by speech, signals, writing, or behavior (Kingsoft 2003). With reference to Oxford English Dictionary, “Communication skills” having the definition as abilities that enable one to communicate effectively with other people, especially considered as a qualification or asset; an aptitude for conveying information and ideas combined with good listening and comprehension skills. As it is one of the essential ability of human kind, that is significantly identifying human characteristic. When communication come into organization, then it is an essential process in organization, the basic functioning of organizations depends on the process of communication. With out communication, organizations can not exist (Greenberg and Baron 1997).

 

To the process of communication, Greenberg and Baron (1997) defining that by which a person, group, or organization (the sender) transmits a piece of information (the message) to another person, group, or organization (the receiver). To clarify the definition they present a diagram summary as Figure 5-A:

Source: Greenberg and Baron, 1998, Behavior in Organizations.

Figure 5-A: The communication process

Mullins (2003) described the communication process in his research of ‘Process of Perception’, identifying that communication and perception are inextricably bound. By interpretive the study between Laurie and Greenberg (and Baron), the author recognize that the ‘decoding process of information’ is the explanation of ‘perception’; might this is the abstractive interpretation. Laurie further identifying that the perception will misjudge, feedback is the vital to reaffirm the perception.

5.2       Barriers to Communication

 

For a successful team work or collaboration in organization, a key element to make it success is communication. Communication come along with many barriers, and the name given that distorting the clarity of information is ‘Noise’, as shown in Figure 5-A. With the latest study, the author recognizes the study by Dimbleby (1998) is more detail into identifying the barriers, he summarize it into the diagram as Figure 5-B:

Source: Dimbleby (1998) p.80.

Figure 5-B: Barriers to communication

 

The author summarizes Dimbleby statement to those barriers as:

Mechanical Barriers – Noise around those talking can resulting in filtration of context. Any breakdowns in equipment involved with communication would also mean the barriers.

Semantic Barriers – Careless use of wording, semantic is to do with the meaning of words. If words are not appropriately they can not produce meaning which are likely to be.

Psychological Barriers – Interpersonal attitudes, beliefs, and values. These are the most common cause of difficulties with interpersonal communication. These barriers filtering what person say it and affect how another person interpret it.

A visualizes view to interpersonal communication process as Figure 5-C:

Figure 5-C: Interpersonal communication process.

 

Source: Dimbleby (1998) More than Words: An Introduction to Communication, p.40.

 

The author recognizes that ‘Interpersonal Communication’ dominated the most important part to the process, might this is the general and universal issues; well, as for software development is involved with many interaction of team dynamic. Despite if there is any engineering vulnerability, communication with the client, the activity defining as “User Requirement Study” has to take serious consideration when undertaking the task. Engineering and development outcome is the consequent of communication between the clients. It is dependent on the sharing of information and establishment of relationships; these are building around the need for project’s objective and the objective orientation.

 

One of the “Interpersonal Communication” major defects in software development is that it completely ignores how clients as the receiver will respond. For example, in the meeting of “Requirement Study” activity, the way the System Analyst respond will be determined largely by the manner in which the message is delivered to the clients. The Project Manager might less concern about the response of the clients than he/she is reading with the report itself. Therefore, one weakness of such a model is its failure to take into consideration the specifics of the sending and receiving process.

Such barriers to communication in software development project, the author recognize the factor from his experiential and summarize as:

 

Technical Jargon / Terminology (the Semantic Barriers)

When communicate with the clients as the receiver, technical jargon will be the majority of semantic barriers to the communication; how should a layman ‘decoding’ the message if a technical person is pushing all of the jargon to it? It is depending to the individual maturity upon how they handling the conversation or meeting with the clients, technical person functioning such as System Analyst serving the role to carry out that task that is gathering client’s needs upon the system, they are the key person who’s put the conceptual design into specification, the process of understanding conceptual requirement from the clients.

One of the core values in the Agile methods (Agile Software Development Model) is emphasizing on communication, Koch (2004) states that all of the Agile methods are designed to optimize communication among the various stakeholders. How does these “technical jargon” can be delivered to the clients?

 

The author recognize that the communication skill to overcome semantic barriers on jargon speaking to the clients, the individual (Project Manager, System Analyst, etc.) require to simplify their conversation into common saying, as well as illustrating the terminology into common object; for example like:

  • when saying “Client-Server” to the clients;

– might commonly illustrate as “Centralize data and information”.

  • when saying “we are using VB .NET (Java, ASP, etc) to develop the system”;

– might common explain into “the tools we used for the development”. As with professional maturity perception to programming tools, should the clients really want to know what tools is that?

  • when saying “this is run-time error”;

– might simplify as “error”. When the terminology ‘run-time’ is omitted, shall the   receiver save his/her decoding process in situation?

  • when saying “the database connection is transporting upon TCP/IP backbone”;

– might explaining as “the information is transmit using a network protocol call TCP/IP”. By highlighting the terminology to the receiver, let the clients distinguish the common explanation with terminology.

 

Assuming of Understanding (the Psychological Barriers)

“Never assume, for it makes an ASS out of U and ME.” (Anon. 2001 author’s note from http://www.quotationspage.com/) Recap the Semantic Barriers by conveying terminology to the clients; the author mention that, by omitting Semantic Barriers shall depending on the professional maturity of an individual, essentially it is come along with the attitude taken when the conversation is held. Shall we depressing our attitude rather than knock-down our clients intended to show our professional? In this kind of situation the clients might drop out the interpretation on what he/she are talking about, and assuming understanding upon the conversation.

 

Listening show high moral on professional care, earn appreciate from the clients. Effective profession takes the time and effort to carefully listen to the clients, as to assume the understandability of the clients rather than listen to them and conduct interactive understandability. Feedback to the communication process this is used to determine whether our message is getting across, whether the receiver agrees or disagrees with it, and where we progress from as a consequence. This is the closing of a loop which we previously ignored (Beech 2002), do not assume.

 

Coding Documentation (the mix of Mechanical & Psychological Barriers)

Koch (2004) stated that the Agile methods is strongly favor face-to-face communication and tend to de-emphasize written documents. Although none of these methods actually intends to eliminate all documentation, Agile methods do militate against documentation that is primarily archival in purpose and emphasize to pay primary attention to communication among project team members. Contemporary software development cycle is emphasizing on ‘software component reusable’, which mean cutting the cost by reinventing the wheel. Review to most of the maturity software development framework and planning, there is having an implementation review task namely ‘project lessons learned’. As this is an overall lessons learned throughout the project, the author recognize that documents on coding shall creating both Mechanical and Psychological Barriers if software engineering teams does not proper stated their ‘written’ communication among the team, this will difficult to carry on ‘reusable of software component’. Others then it is a barriers to component reuse, it also create difficulty to hand over the coding task for others team members. Recap the author’s study into ‘haphazard development phenomenon’ within software development process, ‘coding documentation’ is one of the factor in this haphazard phenomenon.

 

What is team? Collaboration makes it effective. When writing coding documentation to communicate others, identify the technical problem met, the action needed to resolve the problem, gather extra information for further references.

 

5.3       Appendix: Enhancing Communication Skills

 

Communication, how can it become so difficult? It is seen as a rather straightforward approach. Richman (2002) having the suggestion by enhancing individual communication skills in his study in project management:

  • Choose the most appropriate method of transmission for your communication: face-to-face, telephone conversation, voice mail, e-mail, video conference, memo, letter, etc. Determine which method is most appropriate considering the urgency and importance of the message or the need to discuss the issue, make a decision, or negotiate.
  • Prepare your message in advance. Determine how and when to deliver the message. Identify the problem that needs action, gather relevant information, and focus on the most important issues.
  • Deliver the message in a clear and constructive way. Use appropriate nonverbal communication. Be aware of the other person’s feelings and show genuine concern.
  • Listen to the receiver’s message. Really listen. Ask questions until you are sure you understand the response. Accept the fact that the other person may see things differently from how you see them.
  • Verify understanding by summarizing or paraphrasing the response to be sure you understand correctly.

 

 

·         REFERENCES

 

  • Beech, Nic; Cairns, George; Livingstone, Hugh; Lockyer, Cliff; Tsoukas, Hari. 2001, Managing People in Organizations, Volume 1 and 2, University of Strathclyde Graduate School of Business.
  • Bocij, Paul; Chaffey, Dave; Greasley, Andrew; Hickie, Simon 2003, Business Information Systems: Technology, Development and Management for the e-business, Prentice Hall, Gosport.
  • Braha, Dan. 2002, Partitioning Tasks to Product Development Teams. Proceeding of DETC’02 ASME 2002 International Design Engineering Technical Conferences, MIT.
  • Cook, Sarah; Macauley, Steve; Coldicott, Hilary 2004, Change Management Excellence: Using the Fourth Intelligence for Successful Organizational Change, Kogan Page, British Council Malaysia.
  • Dimbleby, Richard. 1998, More than Words: An Introduction to Communication, 3rd Routledge, Canada.
  • Dubrin, Andrew J., 2000, Complete Idiot’s Guide to Leadership, 2nd Alpha Books, Indianapolis.
  • Greenberg, Jerald and Baron, Robert A. 1997, Behavior in Organizations, 7th Prentice Hall.
  • Hendricks, William. 1996, Coaching, Mentoring and Managing, Career Press, Franklin Lakes.
  • Hornby, A.S. (Original work), Lee Bei Da (Translator). 1997, Oxford Advanced Learner’s English-Chinese Dictionary, Oxford University Press (China) Ltd, 3rd Beijing.
  • Kingsoft Powerword 2003, The American Heritage Dictionary, 4th Beijing Kingsoft Corp, Beijing.
  • Koch, Alan. 2004, Agile Software Development: Evaluating the Methods for Your Organization, Artech House; Norwood.
  • Mark C. Paulk, Charles V. Weber, Suzanne M. Garcia, Mary Beth Chrissis, Marilyn Bush, Feb 1993, Key Practices of The Capability Maturity Model sm, Version 1.1, Software Engineering Institute, Technical Report CMU/SEI-93-TR-025, ESC-TR-93-178.
  • Markle, Garold L., 2000, Catalytic Coaching: The End of the Performance Review, Greenwood Publishing Group.
  • McKenna, Eugene and Beech, Nic 2002, Human Resource Management: a concise analysis, Financial Times, imprint of Pearson Education.
  • McNurlin, Barbara C. & Ralph H. Sprague, Jr. 2002, Information Systems Management in Practice, International 5th Edition, Natalie Anderson.
  • Minor, Marianne. 1995, Coaching for Development: Skills for Managers and Team Leaders, Course Technology Crisp.
  • Mullins, Laurie J. 2002, Management and Organisational Behavior, 6th Edition, Pearson Education.
  • Oxford Online, Oxford English Dictionary: The definitive record of the English Language, Oxford University Press, 2005, http://dictionary.oed.com/
  • Pepitone, James S. and Bruce, Anne. 1998, Motivating Employees, McGraw-Hill.
  • Pressman, Roger S. 1997, Software Engineering: A Practitioner’s Approach, International 4th McGraw-Hill, Singapore.
  • Richman, Larry L. 2002, Project Management Step-by-Step, AMACOM division of American Management Association, New York. British Council Malaysia.
  • Shea, Gordon F. 2001, Mentoring: How to Develop Successful Mentor Behaviors, 3rd Course Technology Crisp, Menlo Park.
  • Sommerville, Ian. 2001, Software Engineering, 6th Addison-Wesley, USA.

Leave a Reply

Your email address will not be published. Required fields are marked *