Embed Size (px)
DESCRIPTION
Citation preview
Working as an IT Professional
Professional Accountability
Commitment
Quality
A Statement of Principle
Version 2.0
January 12, 2010
Quality
Cost
ScopeSchedule
i Version 2.0
Contents
Introduction ..................................................... 1
Characteristics of a Professional ..................... 2
Professional Models ........................................ 2
The Role of the Specification ........................... 4
Commitment in Context .................................. 4
Quality as the Integrating Concept .................. 6
Responsibilities of the Client ........................... 7
Commitment and Community ......................... 8
Summary ......................................................... 8
References ....................................................... 9
Quality
Cost
ScopeSchedule
1 Version 2.0
Introduction What are the core responsibilities of an IT practitioner tasked with producing a quality deliverable on time, and within budget? There have been many examples throughout the IT industry where managers have asked teams to step up to a major challenge. Sometimes the problems were not the team’s fault. Other times there were insufficient time and resource to complete the job. Often, the business organization could not afford to miss an excellent opportunity. In such cases, management might ask practitioners to work longer hours than normal to “get the job done.” Is this appropriate, and if so, why does the practitioner accept this as a responsibility?
Many developers have experienced two types of project that require working long hours:
• The death march refers to a project in which morale and quality are poor. The client is dissatisfied and the developers are exhausted.
• In an exceptional project, everyone works very hard to meet or exceed the goal. The client is delighted, all team members have a sense of accomplishment and everyone feels good about the outcome.
The difference in how these two situations are perceived lies in the sense of control and commitment that the IT practitioner experiences. However, the term commitment has a special interpretation explained later in this document.
Challenging projects are a fact of life for the professional. In some cases, the time-‐to-‐market demands outweigh the goal of optimizing quality. In other cases, business managers or external agencies may have made estimating errors, but could not change the dates due to dependencies with other commitments. So why should the IT practitioner take responsibility for these problems?
This document discusses expectations and responsibilities, and in doing so addresses the following questions:
• Are IT practitioners in fact professionals – just like accountants or lawyers?
• What expectations are reasonably placed on a professional?
• How is an IT professional expected to behave?
• How should a professional interact with business representatives (as a subordinate or a vendor)?
• During a challenging project, what are the limits of the responsibility of the professional?
• Who judges quality, and how?
• How are professionals held accountable for their work?
• What is commitment?
In answering these questions, it will become clear that a professional does not act in a vacuum, but participates in a protocol between IT professionals and the other parts of the business organization. When the conditions are right, the professional will step up to the challenge and achieve extraordinary results. This is because a professional’s motivation generally originates from internal factors, but leadership and a good client relationship can transform this basic, inner motivation into true inspiration.
The client organization has a stake in engaging the IT professional in setting goals and timeframes. Death March projects rarely meet the target date the way the client expected, and the collateral damage is often high. Given the opportunity, most business executives would prefer to know the realistic implementation date early enough to make contingency plans. Learning that a team will miss the implementation date just prior to the fact reduces an executive’s options.
When do executives want to know that the water will not fit in the glass?
• When we measure it
• Just before it overflows
• When their feet are wet
Figure 1: The Executive’s Preference
The protocol proposed in this document is that the Business will engage the IT practitioner as a true professional. In turn, the professional will demonstrate commitment by consciously accepting accountability and do what is necessary to deliver quality within an agreed time and budget.
2 Version 2.0
Characteristics of a Professional • Business Economics is the primary motivation
Professionals exhibit many desirable qualities, such as responsiveness, passion and dedication, but these characteristics are rooted in an underlying appreciation of business economics. Professionals do not need passion for the job, and people without passion are not somehow less professional. While passion can leverage other motivations, it is not a key element.
Compared to professional, the term amateur is often used pejoratively. However, the original meaning of amateur (amāre: to love) referred to someone who performed for the love of the activity rather than for payment. The professional was someone who performed for money. Being an amateur was considered a desirable quality in college sports, but not in the workforce. Do professionals need to love their jobs? In fact, no -‐ that is a secondary motivator because it is not driven by economics.
Primarily, economics motivates professionals. They sell a skill for a reward. This is particularly obvious in the case of those people in a professional practice because they bill the client for every hour of work. This distinction is important because amateurs, who work for the love of the discipline, work until they are satisfied. The professional, on the other hand, works until the customer’s specification and their agreement are satisfied. Amateurs, along with artists, are the judges of their quality. For the professional, the specification provides the benchmark for quality.
When practitioners argue that they need to work longer than planned on a task because the product is not up their personal standards for quality, they are not demonstrating higher standards compared to their peers: they are applying, instead, a subjective and amateur standard.
• The motivation to exceed
While business economics and satisfying the client’s needs are the basic motivations that are necessary and sufficient for a “job well done,” leaders and clients recognize that there are other motivations that truly engage a professional employee, that leverage the basic motivations such that professionals will additionally devote their discretionary time and creativity to a project.
Most professionals receive a great deal of satisfaction from internal, personal motivational factors such as: performing what they believe to be a good job, sharpening their skills, and applying their creativity to an important project. Feeling that their contribution is important, and matters, is especially significant. Good leaders recognize that while they can offer external motivators such as recognition or a merit raise, showing how the project goals align with the professional’s goals and inner motivations can result in an extraordinary performance: it becomes truly inspirational. (Hertzberg’s The Motivation to work elaborates on this concept.)
Before expanding on the importance of the specification and its role as the benchmark of quality, it will be useful to review the different types of professional.
Professional Models This section provides IT practitioners with a basis to shape their work practices and determine how they relate to the rest of the organization. Professionals provide services to clients while conforming to codes of practice that protect the interests of the public, employers and peers.
However, they do not all work in the same manner, and the way some professional bodies operate is not appropriate to systems development. Comparing physicians, lawyers, auditors, engineers and consultants demonstrates the broad spectrum of professional behavior.
• The Physician
When patients visit a doctor, they do not bring a personal specification to the consultation. The physician has a model of the parameters for a healthy person: temperature, blood pressure, pulse rate, etc. The physician compares the patient’s condition to this model of the healthy human being and then tells the patient what to do. The doctor knows what is best for the patient and prescribes a treatment.
• The Attorney / Advocate
The attorney acts as a voice for the client. The attorney knows the complex legal codes and which strategies are relevant to the case. The lawyer listens to the client’s story and describes alternative strategies, such as plead guilty, make a plea bargain, or plead innocent. The attorney is generally not
3 Version 2.0
concerned whether the client’s story is true or not: the purpose is to be an advocate. The advocate will tell the client what is possible, and what the various outcomes could be, but will leave the decision over which course of action to take to the client. The attorney’s objective is to ensure the client receives due process, not to ensure an agreed outcome or deliverable.
• The Auditor
Laws and regulations require a client to engage an auditor who protects the interests of third parties such as shareholders and the IRS. Statements of accounting principles defined by the professional bodies and enacted in legislation determine professional behavior. Similar to the advocate, the auditor does not have a specification as such. Each client receives the same process, but also receives a standard deliverable – a statement regarding the audited accounts.
• The Engineer
The engineer listens to the client and identifies requirements. A specification is built based on the engineer’s understanding of engineering principles and codes. The deliverable -‐ a bridge or a chemical plant -‐ can be built according to the specification. The job is complete when the specification is met.
Unlike the physician, the engineer does not have a mental model of “what is best” for the client. The engineer is not a disinterested advocate, promising only to follow a process. The engineer’s view is that the client “knows best” in terms of the function of the deliverable, and to some degree, its form. (Note, this is distinct from the consulting engineer who brings “best practices” from many years of experience with other clients.) The engineer uses knowledge of what is physically possible and codes of practice as a frame of reference for the specification. The engineer will not knowingly build a bridge that will fall down. The commitment is for more than just a process to build a bridge: the commitment is the bridge.
• The Consultant
Clients engage a consultant as an advisor to apply expertise to a problem and provide unbiased recommendations. One of the ways in which they differ from engineers is that they are not generally accountable to construct the recommended solution.
The Institute of Management Consultants (IMC) provides this definition of a management consultant:
“A management consultant is a professional who, for a fee, provides independent and objective advice to management of client organizations to define and achieve their goals through improved utilization of resources. He or she may do this by diagnosing problems and/or opportunities, recommending solutions, and helping implement improvement.”
This description can easily extend to cover other types of consultants. Company employees with the appropriate expertise can function as internal consultants, as long as they follow the consultative approach. However, for very practical reasons, the employer-‐employee relationship can interfere with their objectivity and independence.
Consultants vary greatly based on the depth or generality of their domain expertise. For example, an IT consultant might focus on insurance underwriting practices, whereas a strategic planning consultant would need broad experience of finance, operations, human resources, marketing and sales. However, for all consultants, the domain knowledge is only one part of their value to an organization. It is their training and experience in the consultative approach that guides them to:
• Recognize problems and opportunities;
• Analyze opportunities and diagnose problems;
• Devise or shape alternative solutions based on best practices and experiences gained on other assignments;
• Advise the client by providing a detached, external view of a company's practices and techniques; and
• Recommend an approach
In many respects, the consultant provides value by recognizing problems that others do not see, and shaping solutions based on experiences that others do not have. Nevertheless, the consultative approach guides the client towards making the best possible choices while recognizing the constraints on the business and avoiding any prejudices the consultant might have.
For all types of professional, the client is primarily concerned about the outcome and the costs. The time
4 Version 2.0
recorded for a project is generally secondary. For example, a patient is more interested in a cure than in the actual time the physician spends on the case.
The Role of the Specification The major distinction between these professional models concerns the role of the specification and its impact on the relationship between the professional and the client.
The doctor has a generic specification -‐ a model -‐ for the regular human being. The advocate’s model is the legal code that defines a process to which the client is entitled. As such, the advocate does not have a specification for a deliverable. The consultant uses domain knowledge, and applies a process – the consultative approach – to reach an unbiased recommendation. However, the consultant’s deliverable is based on an assignment brief, not a specification.
The engineer has a special relationship with the client that is most relevant to the role of the IT developer and the systems development process. IT professionals prepare specifications and commit to develop a deliverable on the principle that the client knows best -‐ up to the limits of codes, principles and the law. For example, regardless of the client’s requirements, an IT practitioner will not build a system that allows a manager to embezzle, just as the engineer will not build a bridge designed to collapse.
Clients engage consultants, on the other hand, to address ill-‐defined problems rather than specified problems. While consultants may in fact know what is best for the client (based on best practices), they recognize that the client is the decision-‐maker.
The consultant plays a role mainly in the investigative steps of an IT project, especially during a feasibility study and business process modeling, and may play a role in defining the specification.
However, these two modes of working – the engineer and the consultant, the builder and the advisor -‐ should not be confused or combined during key steps in the systems development process. The client has very different expectations for these two roles.
One interesting distinction between IT practitioners and engineers is that regular engineers do not often re-‐create something that is pre-‐existing, such as replacing one dam with another in the same place. IT
professionals, on the other hand, often automate an existing process and include conversion steps in the project. Secondly, many companies have no experience of employing engineers, and are not familiar with how to manage this professional role.
Figure 2: The Iron Triangle
The well-‐known Iron Triangle depicts three related constraints of scope, schedule, and cost. At best, no more than two of these constraints can be varied independently: the remaining constraint becomes a function of the other two. The engineer and the client can attempt, for example, to increase scope and reduce schedule, but not without increasing cost. In this example, cost cannot remain constrained without seriously affecting quality -‐ which in objective terms means not delivering on the specification.
This is the root of many disagreements between the professional and the client (or the manager), with some parties believing incorrectly that somehow a committed team can overcome these constraints.
However, engineers are not cheerleaders: they do not “give 110%” (because they have highly developed computational skills). Instead, it is their practice to build a factor-‐of-‐two safety margin into their deliverable. IT professionals are rarely given this latitude.
Commitment in Context Commitment is a misunderstood concept. Clients and managers often ask professionals if they are committed to meeting a schedule. Managers might even ask if the professional is committed 110%.
Quality
Cost
ScopeSchedule
5 Version 2.0
However, it is rare that the parties discuss what they mean when they use the term.
“Being committed” cannot contribute to meeting a schedule if it is used simply as an affirmation. The root of commitment lies in the relationship between the engineer, the client and the deliverable, which is shown in the delivery triangle.
Figure 3: The Delivery Triangle
The deliverable is the concrete product resulting from the requirements. The performer agrees to create the deliverable. The acceptor agrees to provide requirements and then accept the deliverable based on it meeting those requirements. This cycle repeats. In an early phase of the project, the performer takes user requirements and creates a specification as a deliverable. In subsequent phases, performers use the specification to create a system as a deliverable.
According to this concept, the professional (the performer) is accountable to the client (the acceptor) for the delivery.
What does this accountability mean? It must be informed accountability, based on as complete an understanding of the specification as is reasonable. The requirements must be complete and visible to all concerned. Progress throughout the project must also be visible to all concerned – this is one purpose of the peer review. In other words, a commitment to deliver without this understanding is empty.
To elaborate, the key factors are:
• Visibility: Information about the requirements, the deliverable, and the project status must be openly discussed in order that the right decisions are made. Production of the deliverable must be transparent by being open to peer review and
testing. Information must be shared as early as possible to allow departments, divisions, teams and individuals to see each other’s commitments, and to adjust to change where necessary.
• Accountability: The performer is the one who must accept accountability for the deliverable based on a complete understanding of the specification, the business constraints and the technical frame of reference, according to the principle of Visibility. Clearly defined accountability for each participant within the project shows who is responsible for each risk, each deliverable component, and each decision.
• Commitment: This can now be defined in terms of an informed consent based on participation in the preparation and negotiation of estimates and schedules. Professionals are committed when they accept accountability for the deliverable. One cannot give accountability to a professional. A manager cannot promise commitment on behalf of another person – only a person who recognizes accountability can accept it.
• Peer Review: Visibility into plans, commitments, status, and achievements of peer organizations and participants can provide encouragement (peer pressure) to fulfill commitments. Group dynamics and team cohesion play an important part in making peer review effective.
Once committed, the professional is responsible and accountable for timely, on-‐budget delivery. This might require working longer and harder than originally estimated to meet the committed date with a quality deliverable. This commitment does not occur at the end of the schedule when a project is in trouble. Every day, the professional reviews progress and does not quit after a specific number of hours, but works until the day’s commitments are met. This principle is part of being a professional and helps to define the limits of the professional’s responsibility. The team can expect professionals to work as hard as necessary to meet their commitments, but only to the extent of those commitments. Teams cannot assign work to an uncommitted person and expect good results.
This last point brings the discussion back to a comment made in the Introduction comparing the death march and the truly exceptional project. Both require extraordinary effort by practitioners, but the outcomes (and memories) are very different. It was
Deliverable
AcceptorPerformer
Deliverable
AcceptorPerformer
Agreement&
Specification
Accepts
Accountability
Delivers
6 Version 2.0
stated that a significant distinction between these two types of project was based in the professional’s perception of commitment and sense of control – or Locus of Control.
Locus of Control is a concept proposed by psychologists such as J Rotter and P Zimbardo to describe peoples’ perception about the underlying causes of events in their lives. Individuals with an internal locus of control believe that outcomes result mainly from their own actions. People with an external locus of control believe events in their lives are contingent on fate or the actions of other, more powerful people (i.e., outside their personal control). They are not convinced that their contribution will affect the outcome of a project.
This is an important concept for professionals and their relationship to the client for two reasons:
• Competent individuals with a high internal locus of control tend to handle stressful projects better. That is, stress does not have such a negative effect upon their performance. They are likely to make more of an effort and persist longer at a task.
• Professionals with a high internal locus of control feel empowered to take responsibility and make a commitment.
Several factors discussed so far contribute to supporting an individual’s perception of control:
• Participating in the estimation process;
• Being able to accept accountability (rather than complying with demands);
• Having visibility into project progress and the commitments of others; and
• Participating in a peer-‐review process.
An internal locus of control, supported by professional competence, ultimately validates and strengthens the professional’s commitment.
All team members, including those with less experience, should have input into estimates. Team leaders and managers “negotiate” the estimates by bringing their own experience to the discussion. Nevertheless, each project participant must be committed in the sense of accepting accountability to deliver a clearly identified piece of the deliverable on time.
Quality as the Integrating Concept This document argues that a certain type of professional, the engineer, is the proper model for the IT professional. Further, professionals are distinguished from amateurs because amateurs work for the love of the task, defining quality according to their own, often high but nonetheless subjective, standards.
The Iron Triangle depicts quality at its center because for a given degree of quality, the relationship between cost, schedule and scope is constrained. Therefore, professionals need a measure or benchmark for quality that is not subjective and is not “artistic.” The specification provides an objective basis for assessment. In professional terms:
Quality is Conformance to the Specification
This is not a recent idea. In 25BC, Vitruvius wrote in “The Ten Books on Architecture” of three principles for designing a building:
• Strength, Utility, and Beauty
By utility, Vitruvius meant that a building must serve a purpose or function according to a specification, and it must be “well adjusted to its site.” By strength, the architect meant that the building must be fit for the purpose for which it was constructed, and not have defects causing it to collapse. Finally, by beauty, this architect was referring to the appearance and use of the building, which is pleasing to the eye and which appeals to the senses according to principles of symmetry.
How does this apply to IT professionals?
The translation is clear. IT deliverables must satisfy the functional requirement (provide utility); they must be shown to be fit for the purpose for which they were designed, perform under load and in conjunction with other systems (strength); and they must be user-‐friendly (beauty) and consistent with architectural principles.
The specification describes these elements and expectations, and a team achieves quality through conformance to the specification. The professional is accountable to the acceptor to deliver quality in these terms.
However, clients should recognize that there is a legal distinction between a professional and an expert:
7 Version 2.0
courts hold experts to a much higher standard. Professionals are allowed to make mistakes – and will do so – but the delivery process should catch and fix these errors. Resolving these types of problems is a natural part of the development process, and should not become a source of conflict.
Responsibilities of the Client Within this model of professionalism, the client has clear responsibilities as the project sponsor or champion, and as the budget authority. Usually, a client appoints delegates for day-‐to-‐day project activities. The professional must understand the limits of the delegate’s authority and remain focused on satisfying the client’s requirements rather than diverting resources to the delegate’s other projects. The client or the client-‐delegates must:
• Be available and actively engaged in the definition of the requirements and, sometimes, in the creation of the specification;
• Understand the limitations of accuracy of most estimates, particularly when problems are ill-‐defined or requirements and technologies are novel;
• Be capable of defining tests, based on the requirements and specification, which can validate and verify the proper functioning of the deliverable; and
• Accept the deliverable once it satisfies the test criteria and, therefore, conforms to the specification.
Clients should realize that the transformation of user requirements into a working system is similar to a translation from English to French: users and technicians each have their own business languages and cultural contexts. Therefore, it is not unusual for something to “get lost in translation.”
Earlier it was stated that the engineer, and therefore the IT development professional, does not claim to know what is best for the client – it is the client’s responsibility to provide requirements and ensure that they have been captured correctly (through acceptance and sign-‐off). As a result, when addressing misunderstandings, the client cannot expect that the IT developer “Should have known what I wanted,” or “Should know how we do business in the field,” or
should have understood some esoteric implication of a requirement, if it is not stated in the requirements.
The client can avoid this problem by:
• Engaging a subject matter expert in the role of a consultant during analysis; and
• Following the consultant’s advice when finalizing requirements.
In this case, the consultant would be responsible for errors and omissions. However, the client must be made aware of the distinction between these very different roles that any specific IT professional can fill – the engineer and the consultant -‐ and the two should not be confused. Otherwise, a key element of scope control will be lost.
When the requirements are silent on a topic, either party’s interpretation could be correct. Clients can validly question why requirements are deficient if they engaged an IT professional in the role of a consultant. In such cases, the client can expect the consultant to modify the requirements, but there may be a consequential change in the estimates. However, clients have the ultimate responsibility for oversights in requirements, given that they are ultimately responsibility for their line of business.
The client-‐professional relationship works best when both parties view it as a customer-‐vendor arrangement, rather than as an employer-‐employee arrangement because the latter relationship has an unbalanced authority structure. Similarly, the professional should not exploit technical knowledge to influence the client unfairly.
Clients and IT professionals should work as partners; approaching errors, omissions and change orders from a balanced perspective and not using deadlines or other constraints to force one party or the other to absorb the impact of discoveries and change.
The client should be a champion for the project and regularly communicate its importance to the team. This helps professionals to build the linkage between the project goals and their own internally driven motivations.
Often, there is a gap between theory and practice, and some users may not share these principles, nor be ready to adopt the role as client. However, the IT professional can lead by example and clearly demonstrate the benefits of this approach over time.
8 Version 2.0
Commitment and Community Looking at the implications of commitment within the organizational context, Rosabeth Moss Kanter (A previous editor of the Harvard Business Review) provided several insights in “Commitment and Community” (Kanter 1972) in which she studied the foundations and characteristics of commitment in utopian communal orders. Kanter determined that:
• A committed person is invested, loyal, and involved, and feels that the team is an extension of the person.
• Investment by an individual occurs when the person gains a stake in the organization.
• The group must provide guidance in the form of specific behavioral norms and detailed instructions.
• Regarding group pressure and social control, groups can replace the repressive, distant control of impersonal institutions with the pressure of an intimate, face-‐to-‐face group of peers (peer pressure).
• Peer pressure can be a very strong force in influencing members to meet commitments.
• Openness, or visibility into performance and commitments, is a strong sanctioning motivation to conform.
• Regular contact between group members increases commitment.
• Successful organizations employed mutual criticism and feedback, and had frequent meetings to share information.
• Group pressure plays a large role in the life of the community, and in some communities was the primary form of social control. Members reported great unease at “letting down the group.”
• Those communities that worked best managed to generate commitment and loyalty in their members, immersing them in a strong group that often asked them to make sacrifices.
These points support the view that the role of the peer review in IT delivery is crucial. Within a team of professionals, the openness and visibility associated with peer review leads to peer-‐pressure to conform to the organization’s standards and to support the team.
This mechanism helps to engage and monitor commitment. Team members are more than an aggregate of individuals; they are part of a group with responsibilities for the success of that group. Professionals recognize that, for the group’s benefit, they may need to extend their original commitments as conditions change. However, any increase in commitment should be accepted according to the principles outlined in this document.
Summary • Engineering provides the best professional role
models for the IT practitioner during a development project.
• Consultants are good role models for subject matter experts during business process modeling, feasibility studies and other activities where the client wants unbiased advice.
• Professionals should clearly define whether they are acting in the role of the engineer or the consultant.
• The specification is a distinguishing factor in the relationship between the professional (the performer) and the client (the acceptor).
• The Scope in the Iron Triangle (of Resources – Schedule – Scope), becomes the Specification in the Delivery Triangle (of Performer – Deliverable – Acceptor).
• The Delivery Triangle explains the accountability of the performer, to the acceptor, to create the deliverable.
• Through an understanding of the requirements in the specification, and through participation in setting the three constraints of the Iron Triangle, the performer becomes accountable. Only by accepting accountability does the performer become truly committed.
• Accountability and commitment require visibility and peer review.
• The limits of a professional’s responsibility are defined within the specification to the extent that the professional has accepted accountability and is committed.
• Professionals define quality as conformance to the specification. Its characteristics include
9 Version 2.0
functionality, fitness for purpose, and user-‐friendliness.
• Peer review and visibility are essential for ensuring quality.
• The client (the acceptor) judges quality against the specification.
• Professionals are not necessarily experts – they make mistakes. Clients recognize that there is a process to manage errors.
• A balanced power structure between client and professional fosters project success.
In conclusion, the committed professional understands the relationship with the client, accepts accountability for the deliverable, accepts peer review as a normal part of the process and works towards a team goal of delivering the scope with quality within a schedule and budget. In collaborating with the client to set the parameters of the Iron Triangle, the professional becomes accountable and committed according to the Delivery Triangle. Commitment does not end after a specific number of hours – it continues until the day’s tasks are complete. Combining this type of commitment with inspirational leadership will result in the fully motivated engagement of the professional -‐ and startling achievements.
Note that the principles presented in this paper are not dependent upon a specific delivery methodology. While the granularity of deliverables is finer and the interactions between clients and other project team members are more continuous and iterative in Agile environments than in, say, waterfall projects, the overarching professional relationship remains the same.
There are practical challenges with this paper’s proposition:
• In some cases, users might not accept the role and responsibilities of being the client.
• When IT professionals are employees of the client’s organization, it can interfere with their objectivity and independence. It can also result in an unbalanced authority structure because, unlike a vendor, internal teams do not have a contract.
• Short-‐term thinking can lead managers to believe, mistakenly, that they can get extra productivity simply by demanding more – by asking for
“110%”. However, this will inevitably undermine the commitment of the most productive employees.
These conditions can make it harder for the IT practitioner to perform according to the model outlined in this document. Arguably, both parties in the Delivery Triangle need to agree to the same protocol for the process to function smoothly. However, it is the responsibility of professionals to lead by example and take the first step. In doing so, they can define themselves by shaping their own principles and practices.
References
Herzberg, F., Mausner, B., & Snyderman, B. B. (1959). “The Motivation to Work”
IMC (Institute of Management Consultants) website, referenced December 2009 at: http://www.imcusa.org/
Kanter R. M. (1972), “Commitment and Community,” Harvard University Press.
Maslow, A. H. (1970). “Motivation and Personality”
Roth, L. M., (1993), “Understanding Architecture,” HarperCollins.
Rotter, J.B. (1954). “Social learning and clinical psychology” New York: Prentice-‐Hall.
USAID (1998): Charles C., McNulty S., & Pennell J. “Partnering For Results: A Users Guide to Intersectoral Partnering,” US Agency for International Development.
Vitruvius, (1960), “The Ten Books on Architecture,” Dover Publishing. (Written in 25BC)
