What type of leader/manager are you? What style of leadership are you comfortable with? I am a lead from the front/setting the example type of leader. Use the attached word doc as a reference. No more

4. YOUR PM Techniques

4.1 Introduction

4.2 A People First, Foundation

4.2.1 The Scenario

4.2.2 Building a Good First Impression

4.2.3 Recruiting the Project Team

4.3 Constructing a Team

4.3.1 Team Dynamics and Team Relationships

4.3.2 Team Work and Team Cohesion

4.4 A People First Manager

4.4.1 Being a “Human” Project Manager

4.4.2 Being a “Leader” Project Manager

4.4.3 Your Personal PM Credo

4.1. Introduction

Now, that the foundation project management theory has been covered, let’s push that all to the side, and start your project management from a “clean sheet”. … And, tailor a project management methodology specific to your leadership style and to your personality traits; as well as, compensating for your employer’s (the performing organization’s) processes & procedures, and taking into consideration your customer’s expectations of, “what a professional should do”.

Remembering that, “SUCCEED IS OPINIONATED”, … And, for a project to be deemed a success is very much dependent on the primary stakeholders’ judgment of the project as having been delivered; within the agreed [Time] frame, within the agreed [Cost] budget, with the agreed [Scope] of deliverables, with the agreed level of [Quality] using the agreed assignment of [People], and using the agreed allotment of [Resources]. And that is, irrespective of what project management methodology was | is utilized.

So, DO NOT EXPECT the project to be deemed a SUCCESS, just because you happened to have followed some prescribed project management methodology to the nth degree; as though, the written text on this methodology was gospel and not as a suggested guide.

Hence, I would recommend that, you start by taking some recognized project management methodology, which you feel comfortable with, and use this as the foundation on which to build your own project management techniques. … And then, continually adapting “your techniques” to deal with the current real-world situation & prevailing circumstances, by emphasizing those aspects which add value while deemphasizing other aspects which evidently aren’t contributing to achieving your current project’s successful outcome.

“As well as, blending in field-tested industrial best-practices, and incorporating those lessons learnt by yourself (and by others).”

4.2. A People First, Foundation

4.2.1. The Scenario

Well, the interview was a success, and today your start your new job at this smallish company that wants to build a bespoke product. … Thinking back, the interviewing manager spent a noticeable amount of time talking about how this “greenfield” development project is going to produce a “market leading” “innovative” “cutting edge” product. … And, when offering you the position, the hiring manager made a closing remark that, “this project should be a walk in the park for you, given your extensive technical experience”.

4.2.2. Building A Good First Impression

Your project (and all future projects, at that performing organization) starts the moment that you walk through the front door of the office, and are greeted at reception. Actually, it all started the moment that you were being interviewed for the role, and continued onto when you subsequently accepted the job offer.

“First impressions count”, and these impressions are the foundations on which successful (or failed) working relationships are built. … And, this first impression is not limited to how you look, how you speak, and how you act; but rather, by whom this is perceived. … And, these perceivers are not limited to your bosses and the customer representatives, but also include; the receptionist, the office administrator, IT admins & support, the stores person, etc., i.e. those persons who form the underlying infrastructure on which your project operates (and hence your project management career resides). As these people’s willful cooperation at some point in the near future could be the difference between your project (and your career) continuing in the right direction or taking a nose dive.

Which brings us to the next rule of “Adapting & Proactive” SDLC Project Management

RULE 33: First impressions, like a first date, establish the foundations for either a good or bad future relationship.

RULE 33A: A bad first impression take some amount of effort to recover from, and requires consistency of desirable behavior (from the wrong-doer) to re-establish the potential for a good future relationship.

Building A Good First Impression, of PM you

Yes, building that first good impression.

1. Dress appropriately for the occasion. … unless specified otherwise, dress ready to achieve the business’s objectives that are the purpose of your coming to work at this particular organization (and location). Though, do conform to prescribed norms, as how a person dresses, speaks, behaves, and their quirkiness traits can influence the judgment of their (potential) performance and their perceived worth.

2. Introduce yourself. … especially when you or they are new to the organization / project, then introduce yourself, calmly & politely, confidently but not arrogantly, as “the project manager”.

With a new Project Implementation Team (who have not worked with your previously), introduce yourself, give a brief background to your work history (try to make this relevant to “their project” that you will be managing. That is, strive to build up their initial confidence that you know what you are doing, and also make it clear that you intend to quickly come up to the speed with the goings on with the project.

1. Confident, but not arrogant. The Project Manager needs to present a demeanor of confidence in one’s own abilities. However, NOT to be perceived as arrogantly self-assured and overconfident, as this type of demeanor can result in the manager being prejudged as someone who is prone to making rash decisions, as someone who will commit the Project Implementation Team to things that should never be agreed to, and as someone who will ignore the input | opinions | advice | recommendations from those “little people” who are subordinate to that manager’s titled-position.

DO NOT expect to receive the respect of the Project Implementation Team just because you have been officially given the title of “Project Manager”.

To obtain the respect of The Team will require you, as the project’ manager, to earn and be worthy of such respect.

DO NOT consider the project hierarchy as a pyramid where (you as) the Project Manager sit at the top issuing decrees to your minions down below.

Rather, consider the Project Manager to Project Implementation Team arrangement as a flat hierarchy (possibly involving some form of mentoring) where the project’s manager takes care of the non-technical matters (such as responding to stakeholder needs & wants, and dealing with inter-stakeholder politics), while The Team takes care of the technical aspects.

Which brings us to the next rule of “Adaptive & Proactive” SDLC Project Management

RULE 34: True respect is earned by deeds, not bestowed by title.

1. Be a good listener, not a know-it-all … No one wants to work for someone who thinks they know everything and who doesn’t listen to anyone (aka “I’m the smartest person in this room”). Because, after a while of having their input & past experiences continually ignored, many a project team member will start to question why they should “give a damn” about the project, let alone spend the time to communicate with the Project Manager. … And, once this communications breakdown occurs, then risks & issues confronting the project can go unmentioned, which could result in some “arrogant know-it-all” project manager being splattered by the “proverbial bus”; because, no one was willing & prepared to tell them the truth of the true-state of things, nor bothered to provide meaningful input | opinions |recommendations.

2. Show interest in each person. … in small groups or one-on-one find out;

ᴏ What are each of The Team member’s names?

Even if this is only their first name (not surname), and remember this by writing it down on a mud-map sketch of the office and where they usually sit.

ᴏ What are their roles within the project and within the organization?

ᴏ What part of the product / system / application architecture are they working on and are responsible for?

Partake in the occasional coffee room “small talk” and get to know each one of them; their background, their interests, and pick up on their home life circumstances.

“Do they have children, and what did they do on the weekend?”

Hence, show some interest in them as individual human beings.

“At the end of the first day, and each day thereafter, when you get home from work and chill-out, can you mentally in your mind, walk around the work place and name each person, at least their first-name, and list something unique about one of them?”

1. Know the stuff that they would expect the Project Manager to know.

ᴏ Know the basic principles & concepts behind project management, and be familiar with the implementation methodology being used by the Project Implementation Team. This does not necessarily mean that you have to be certified in this or that, but it does mean that you understand how & why the project should be undertaken in specific ways, and the “relevant” project management practices that should be considered for use.

ᴏ Know what is happening with the Project Implementation Team, around the project, and within the performing organization; as The Team won’t be too appreciative if any nasty surprises befall the project or them. Therefore, keep a watchful eye on the risks & issues confronting the project. This will mean that you as the project’s manager will have to learn to “network” with other parties within the performing organization (and external to the organization).

Much can be achieved by building up friendly working relationships with other people within the organization; especially working relationships with your peer project managers, and with various people in different positions within the organization (as well as within the customer organization and with 3rd Party contractors / vendors / suppliers).

1. Quickly come up to speed.

ᴏ Know the basic details of the project that you are to manage. This means knowing; the overview of the project, the assumptions made about the project, the scope boundaries of the project, the constraints imposed on the project, the priorities associated with the project, the general requirements of the project (or at least where to quickly find these and extract the relevant information), what are the project’s deliverables, and the relevant dates for the project’s major milestones.

ᴏ Know the basic architectural details of the project’s product / system / application that is being implemented. This does not mean that you have to become a subject matter expert, but it does mean that, you are able to draw a relatively simple block-diagram explaining how it all fits together. … And, more specifically, you are able to point to what sections certain project team members (or sub-teams) are working on and are responsible for.

ᴏ Know the basic details of the technologies & processes underlying the project’s product / system / application that is being delivered. This does not mean that you have to become a subject matter expert, by you will need to at least have an understanding of what the Project Team members (and the project stakeholders) are talking about.

Which brings us to the next rule of “Adaptive & Proactive” SDLC Project Management.

RULE 35: You cannot hope to manage that which you do not know or reasonably understand what is going on.

1. Be enthusiastic about the project, about the Project Implementation Team, and about the project being a future success. … “Not a pessimistic, grim-reaper.”

4.2.3. Recruiting the Project Team

As the Project Manager, it is very important that you strive to build a cooperative & collaboration Project Implementation Team; as it is not the Project Manager, but rather “The Team” who transform the project from mental concepts into physical deliverables.

For each project undertaken, one of the following team construct scenarios will transpire:

1. The Project Manager is new to the performing organization, and the members of the Project Implementation Team are also new (or have yet to be hired).

2. The Project Manager is new to the performing organization, but some (or all) of the members of the Project Implementation Team are already established as a team at the replacing a previous project manager who was either “promoted internally” or who “decided to leave”. … Thus, leaving the new project manager with little to no handover of project related information.

3. The Project Manager is established at the performing organization, and the members of the Project Implementation Team are new to the organization (or have yet to be hired). … Or, The Team members are “old hands” at the organization, but they have never really worked together before as an SDLC Project Implementation Team.

4. The Project Manager is established at the performing organization, and the members of the Project Implementation Team are also well established at the organization extension to this scenario is that of a pre-established Project Implementation Team with its regular project manager.

For this scenario, it will be a combination of (a) and (b), where the Project Manager is new, some members of the Project Implementation Team will also be new, and the other members are old hands that are yet to join The Team in significant numbers.

NOTE: There is a major caveat when it comes to the recruitment of personnel for the Project Implementation Team; as your performing organization most probably has defined processes & procedures related specifically to recruitment, and this could be undertaken by specific staff (possibly involving senior management) who do the entire process without consultation with the project’s manager. Therefore, as the Project Manager, you may not be involved with any part of recruiting the Project Implementation Team. Thus, you may simply have to make do with the “resources” that have been assigned to your project.

Hence, what is contained in this section could be constrained by pre-existing business guidelines & practices. However, what follows should provide you with food-for-thought, when it comes time for you to undertake the recruitment of “people”. … And, especially when you are planning and budgeting for this aspect of your project.

Know Which Positions Need To Be Filled

If you were building your fantasy football league team, then you know that there are specific positions on The Team that have to be filled, else you won’t have a complete team with which to compete.

Secondly, The Team only has a certain sized budget with which to “buy” its players and the associated coaching staff. To exceed The Team’s allotted “salary-cap” could mean that The Club (aka, the performing organization) is driven into financial ruin; let alone the possibility that the Competition’s Governing Body (aka, the customer organization) could fine The Club for breaching the assigned salary-cap, and/or they could exclude The Club from this year’s competition, and/or they could ban The Club from competing in next year’s competition (aka, no more contracted work for this performing organization).

Thus, what positions on The Team do you need to field to be competitive, while remaining within the allocated budget?

…

Unfortunately, there is seldom the availability of personnel within the performing organization to stack The Team with “star player” implementers. Hence, financially & availability wise, the Project Implementation Team has to be composed of a mixture of senior, middle, and junior implementers who will have to fulfill a hybridization of various roles on The Team. As the performing organization cannot (literally) afford to have one person filling only one role; rather, each selected team member has to provide (partial or complete) coverage of several roles. Hence, the purpose of the project’s manager is to build a team that doesn’t have any field position gaps. … while remaining within the allocated budget.

Therefore, based on the skill levels and past experiences of the currently available project team members (including those recruited to join the organization), compose a list of the necessary skills & desired experiences that any potential candidates would have to demonstrate proficiently, so as to be considered for a position on The Team.

Sourcing Those Potential Position Candidates

Those potential position candidates can be recruited via various means, such as; “networking” with former work colleagues, directly advertising the role yourself, or indirectly through the services of a recruiting agent(s).

NETWORK RECRUITMENT … involves recruiting via personal contacts that you (and other team members) have worked with previously at other organizations.

If using Network Recruitment then you have to go into it with the same perspective as you would “if you were to be dropped behind enemy lines, then who would you want to be on your commando team, covering your back”.

Because, by recommending a personal contact to your current employer then you are in affect going guarantor for that person’s performance. Hence, if they underperform or screw-up then this will reflect badly on you; however, if they do perform well then this will effectively bring positive credit to yourself.

Therefore, when personally recommending someone for a position at your employer’s organization, only do this because (in all honesty) you believe that your nominee is one of the best candidates that could apply for the role. Conversely, do not recommend a personal contact, if the primary reason for doing so is as a favor to them (to “get them a job”). … And, don’t sell your personal contact a job that you know is not right for them.

There are distinct advantages with engaging previous work colleagues, especially if you can bring on-board a group of them:

The self-assuredness of knowing in advance that the personal contact is most probably going to perform positively as they did in the past; whereas, a completely unknown person could turn out to be a performance disaster.

Some portion of The Team relationship dynamics of Forming – Storming – Norming – Performing, will possibly carry over from the previous working relationship and thereby serve as a catalyst for team building within the new team.

By placing previous work colleagues in “strategic” team positions then tried & tested work practices & work ethic expectations can carry over from the previous working relationship. This can also reduce the combined efforts involved with “training” new team members as to the SDLC methodology that is to be used on the project.

The significant saving in [Time] & [Cost] that is involved with recruitment when compared to direct self-advertisement and engaging recruiting agents.

“I was one of the first hires for a start-up company, and on my personal recommendations to the owners, they hired my former boss as the group manager, the systems architect, and several of the engineering staff (including juniors and seniors). These personal contacts once hired, in turn recommend other people, and so on, until in a relatively short time a well-rounded development group was built-up, with unknown persons fitting into already gelling project teams. Consequently, productivity rocketed sky-high to greatly exceed that which could have ever been achieved by composing the group entirely from unknown persons.

It was as though, specific parts of the development group were functioning telepathically, with the right-hand knowing in advance what the left-hand was doing. And, with many of the people knowing the processes & procedures to be followed, then those who didn’t know the routine were shown how to by their peers.”

However, there are dangers with impregnating the Project Implementation Team(s) with former work colleagues, as those persons could be perceived as having “too familiar a relationship” with the Project Manager, which could be perceived as disadvantaging those team members who didn’t have that pre-existing working relationship. … And, if The Team consists of noticeable proportions of both previous work colleagues and old-hands from the current organization, then underlying tensions & conflicts can simmer away due to “them and us” mentality. … “which necessitates the building of a bridge between the two factions.”

SELF-ADVERTISEMENT RECRUITMENT … involves the performing organization, by themselves, undertaking public recruitment for The Team position(s).

To do this type of recruitment successfully requires:

1. Clearly defining in the advertisement what the performing organization is looking for and the range of experience that is desired. … DO NOT cram the advertisement with “a mile long” wish-list of skills & requirements; where realistically, no individual candidate is going to have most of those skills. As this bloated advertisement could scare away some of those best-fit potential candidates, and other best-fit candidates could be drowned out by the flood of half-fit candidates who possess some of those mass listed skills. Thus, keep the “must haves” list to those absolutely essential skills and those highly desirable experiences.

2. The advertisement should not be a marketing exercise for the performing organization. For example; if existing staff read the advertisement and joke about the contents with comments like, “yah, right, is that us” or “what a load of rubbish”, then you can expect some of those best-fit potential candidates to also see through this marketing dribble and then decide to skip applying for this role.

3. Once the advertisement is placed onto a job-seekers website then expect to be inundated with applications from variously skilled candidates. Depending on the current economic conditions of the involved SDLC industry, there could be as many as 100 (or more) applicant resumes & cover-letters continually streaming into the recruiting manager’s email inbox. Every one of these applications should be skimmed through, so as to construct a shortlist of candidates that should be evaluated further, and so on, until a shorter list is produced of candidates worthy of interviewing.

Remember that, [Time][Costs] money, and each candidate’s resume & cover-letter is going to take some time to skim through, so as to “sort the wheat from the chaff”. For middle & senior positions this could take at a minimum 5 minutes per candidate document to be reviewed. … Multiply 5 minutes review time by (say) 100 candidates equals 500 minutes which equates to 8 + hours, with an hourly rate of (say) $125 “bums on seat” cost of the reviewing manager’s time equals $1000 per day to skim through these resumes. Then the next day is spent rereading through the shortlisted candidates’ resumes with a bit more diligence, so as to produce a shorter list of potential candidates, and that is another $1000 per day. Then a senior manager (or two) will want to look at the shortlisted candidates’ resumes, then discuss those candidates, so add a few more $1000s worth of [Time] to the tally. Then those shorter shortlisted candidates would be phone interviewed to get the list down to a few candidates that are worth face-to-face interviewing. … So, that is somewhere between $5K to $10K in [Time][Cost], possibly more depending on the organization’s recruiting procedures, to just get to the interview invitation stage (and not to the actual interviewing).

“At this point, Network Recruitment is sounding like a real bargain.”

A resume is like a second-hand car advertisement; what sounds great on paper could turn out to be a “lemon” when put to the test.

Hence, the recruiting manager needs to, in advance of placing the job advertisement, create a scorecard of the “must haves” and the “desirable experiences”, so that each appropriately sounding candidate’s resume (and cover-letter) can be quantifiably evaluated. Thereby, hopefully picking the best-fit candidates to be taken to the next round in the recruitment process.

1. The phone interview’s purpose is to confirm that the potential candidate’s spoken words does correspond with their submitted resume, to established that the candidate can put together understandable sentences, to establish that the candidate understands the technical & industrial field that the project is based, and to confirm that the candidate has the necessary work rights (i.e. citizenship, permanent residency, accreditations, clearances) that are required as a prerequisite for the position that is being recruited for. … And, thereby determining those candidates that are worth being invited to a face-to-face interview.

A PERSONAL EXPERIENCE … The “puppy dog fetch” test of a graduate candidate.

The reality is, most recent graduate candidates don’t have the relevant work experience nor the practical skills to be judged for an SDLC implementer’s role. They could be judged based on their academic record, but the appropriateness of this is very much dependent on the structure of the course(s) that they did; as their course could have been mostly theory with minimal “hands-on” practical assignment work, or a 50-50 balance of theory versus practical, or it could have predominately practical.

Fortunately, for me, the local universities provide all of their graduates with the same generic resume template. Hence, for those graduate candidates who make it through the telephone interview round, when I call the candidate to invite them in for a face-to-face interview, I also request that they make specific changes to their resume, “to make it more specific to engineering roles”. Additionally, I ask them to put together a two page summation of their final year’s project, where I list the sections and what to include. Similarly for a graphical user interface developer, I would ask them to prepare a few page portfolio of their work, where I suggest that they include a website design sketch, a wireframe mock-up, and the final graphics page(s). … And, I emphasize the importance that they, “email me the updated resume and attachment as soon as possible, so that I can present it to my bosses”; then, I come to an agreement with the candidate as to when they will be able to provide the requested deliverables.

In factuality, what I am interested in is; (1) how soon does the graduate candidate email me back their updated resume, (2) with the attached document, and (3) how well do these deliverables conform with my instructions & specifications.

IMHO, the important ingredients of a graduate implementer is their enthusiasm, their willingness to learn, and their ability to follow instructions. Hence, this “puppy dog fetch” test allows them to demonstrate exactly this, and it also shows how much they really do want the implementer’s role that is on offer.

P.S. every recent graduate who has excelled at this test, when hired, has performed way beyond the expectations of senior management.

AGENT RECRUITMENT … involves engaging the services of a specialist company / person to take care of finding those potential candidates; after which, the performing organization does the final rounds of candidate interviewing.

The first thing to realize about engaging recruitment agents is that, often they don’t have the technical background to be able to spot those candidates who truly do have the right skillset and relevant work experience. Rather, the agent is reliant on keyword searching through collections of resumes, targeting the “most ticks” matches. Hence, for this type of agent to be effective requires that the performing organization provides the agent with a precise short list of “must have” technical skills & desired experiences, and then spend some time explaining what these mean. … Else, the recruiting process will end up being a “lucky dip” search of random chance selections; that, they put forward best-fit candidates.

Secondly, realize that many an agent is paid based on commission, and hence their aim is to place as many hired candidates in as short a time as possible. Thus, some agents who have not been in the local recruiting industry “for decades”, won’t necessarily consider the compatibilities of the personalities & attitudes of both the potential candidate and the performing organization, which would eventually have to work together.

Though, using a recruiting agent does have the distinct advantage of not wasting the organization’s management [Time] and effort sifting through those piles of half-fit candidate resumes.

Which brings us to the next rule of “Adaptive & Proactive” SDLC Project Management

RULE 36: Recruitment is not a lucky dip; rather, it is a defined & logical search for the best-fit candidates from both a technical skills and past experiences perspective, as well as compatibility of personalities and attitudes.

Interviewing Those Chosen Position Candidates

Firstly, interviewing is not an ad-hoc make-it-up as you-go get together; rather, it is serious business with specific objectives and desired outcomes.

The purpose of interviewing is to:

1. Give the candidate the opportunity to sell their capabilities & experiences to the performing organization, via bi-directional communications with the interviewers.

2. Determine the best-fit candidate for the role that has to be filled (right now).

3. Determine the candidate who will provide benefit & add value to the performing organization (and to the project), from both technical & interpersonal perspectives.

4. Selling to the “desired candidate” the idea that joining the performing organization (and the project) is advantageous to themselves.

What the interview should never be, is:

NOT a power-trip for the interviewing manager to belittle and/or intimidate the candidate (and those other interview participants) to let them know who is boss.

NOT self-justification for the interviewing manager’s position.

NOT a quest to find “yes-men” “worker-drones” who, when hired, won’t be potential threats to the interviewing manager’s position. … And, it is definitely.

NOT making up the numbers as cover for hiring a preferred preselected candidate.

Which brings us to an addendum to “Adaptive & Proactive” SDLC Project Management.

RULE 36A: The interviewer’s goal is to find the candidate with the best fit capabilities & experiences, who would add value & provide benefit to the organization. … And, to the current project.

When interviewing, there are a few things to watch out for with respect to your technique:

DO NOT do all of the talking, as this makes the interview a complete waste of time; because, when is the candidate going to be given the opportunity to “hero or zero” themself as the best-fit for the role that is being recruited for.

DO NOT ask a question unless it has a definite purpose and a desired outcome to reveal some information by which to further evaluate the candidate. … And, this is not necessarily to find the candidate with the best-fit qualifications who also matches all of the predefined expectations; but rather, to find the candidate who will provide benefit and add value to your employer (the performing organization).

DO NOT waste time asking template interview questions that the candidate has probably been asked umpteen times before; because, the candidate has by now formulated standardized (rehearsed) answers to such questions, and hence the answers may not be a true reflection of the candidate. … “Rather, their answers of a reworded responses that they found via an interest not search.”

For example, “where do you see yourself in 5 years time”, “what are your personality strengths and weaknesses” “what do you see as your most significant achievement”.

Noting that, the HR interviewer and senior manager(s) will probably ask these very same template interview questions. But what they can’t ask proficiently, are those SDLC related technical & practical questions, which are within the realm of your responsibility as the project’s manager; so, concentrate on these questions instead.

DO NOT ask a question (or word a question) that could be perceived as prejudice, in any form, whether this be in jest or not. That is, sexist, racist, religious bigoted … etc.

DO NOT tailor questions to wordsmith answers (i.e. competency based interview questioning); because, this is an SDLC project for which the candidate is being interviewed. What is important, is, … determining the candidate’s implementation capabilities, past experiences, and their technical & interpersonal value to The Team.

COFFEE BREAK DISCUSSION … Competency Based Interviewing, is wrong for SDLC

Competency Based interviewing – where the purpose of this interview style is to predict future performance based on past performances in similar situations. … And, if the interview candidate has been pre-groomed properly, then all the candidate has to do is pick (what sounds like) a real-life example case and answer in the format of:

1.. Summarize the [S]ituation; including the where, the when, the whom was involved, and the potential consequence of inaction.

2.. Summarize the [T]ask / [O]bjective that was required of you.

3.. Summarize the [A]ction that YOU took focusing on YOUR CONTRIBUTION and not that of the group; i.e. “I DID” and not “we did”.

4.. Summarize the [R]esultant (positive) outcome of your actions, and what did you learn from the experience.

IMHO, competency based interviewing is inappropriate when it comes to engineers / coders / testers / implementers because these people are not wordsmiths; but rather, they are “doers” whose purpose is to get things done. … And, where “WE DID” is more important to the Project Implementation Team getting things done, than the “I did”.

“I was once going for this technical role and the recruiter prepared me with competency based interview questions, where the recruiter reorganized each of my answers into the desired S.T.A.R. format. The first time, the agent’s reword of my answer was impressive; but, by the third time, it felt like a con-man’s scam, as here was this agent who had absolutely zero technical skills & experience in that field, yet his answers were perfect enough that it would have been hard to Pass him over for the role.”

And, therein lies the problem with competency based interviewing, it is not targeted at finding the “best doer” for the job; rather, it gets the best answer from a “wordsmith”.

“Oh, and these type of questions can be answered by relating what someone else did and then claiming those actions as your own.”

COFFEE BREAK DISCUSSION … Aptitude Testing is racist, sexist, and wrong for SDLC.

Aptitude Testing – where the interview candidate is given a series of numerical, verbal, and diagrammatic (spiral) reasoning questions. Sometimes this is combined with a sequence of written instructions where the process flow goes around & round & round (for half an hour per question) to eventually end up with some numerical answer.

IMHO, aptitude based testing is inappropriate for engineers / coders / testers / implementers because; firstly it is racist & anti-native language speaker prejudice, secondly it is sexist, and thirdly it is not related to the technical skills required of the person to get the implementation job done.

Racist & anti-native speaker prejudice – today’s engineering community is ethnically diverse, and thus many of the interview candidates will potentially not have the interviewing language as their first-language; hence, such questions as “what is the difference between affect and effect”, “lock is to key as pen is to”, and “negative-not-case sentence constructs”, does put these ethnic candidates at a linguistic disadvantage.

Sexist – males typically have better spatial abilities then women; hence, taking a two-dimensional image on the paper then converting it to a three-dimensional object in their mind then rotating this object in headspace then converting it back to two-dimensions can put female candidates at a spatial disadvantage. Similarly, males typically perform better at mathematical tasks and numerical sequences than do females.

In all honesty, what do these numerical, verbal, and diagrammatic (spatial) reasoning questions have to do with being a good engineer / coder / tester / Implementer?

Why eliminate these potential candidates simply due to a series of questions that are completely unrelated to getting SDLC things done? And, therein lies the problem with aptitude testing, it is not targeted at determining the “best doer” for the job, let alone contributing to building the “best doer team”.

“IMHO, aptitude testing is on academic theorist’s con-job to prove how smart they are, and not how appropriate a DOER is the candidate.”

A Recipe For An SDLC interview … “show us what you can do”

Let the HR interviewer and/or senior management open the interview process with their behavioral interview questions, and the introduction to the organization. After which it is your turn, as the technical interviewer, to do some proper SDLC interviewing.

1.. Prepare the location. … In a quiet place with space for 4 to 5 participants, such as the meeting room (near as possible to the Project Implementation Team’s area). Preferably, set an open seating arrangement where all of the participants are not “shielded” behind a table, and that there is room for participants to stand-up and utilize a whiteboard. … “Make sure the whiteboard marker pens do work.”

2.. One-on-one opening. … With just the candidate and you (the interviewing manager) sit down in the interviewing place (without the other participants present) and have a short friendly social chat “about the weather”, “their journey to the interview”, and most importantly, “thank you for coming in” to be interviewed.

Do a quick introduction to the organization, though ask if this has already been covered during the earlier HR Department / senior management interview.

Ask the candidate if they have checked-out your company’s website, and ask the candidate to, “briefly describe what our company does”.

Ask the candidate to, “briefly summarize” their “career thus far”.

The purpose of these opening questions is to:

1. Establish the interview location, provide time to get used to each other’s spoken words (accents), and to provide a baseline as to their defensive body language. Knowing that, the candidate will be nervous and naturally defensive; so watch for their hands clenched, arms crossed, or their hands on their knees as though they are ready to sprint for the door. Your objective as the interviewing manager is to make the candidate feel at ease; thereby, getting them to drop their defenses, and thus exposing the implementer that resides within them.

2. Determine their interest in the organization by the candidate demonstrating that they have at least spent some time researching your company, and to see if they picked-up anything from the earlier HR / senior management interview.

3. To check that the candidate’s resume does match with what they are saying.

.. Zoning their skills. … For an SDLC project, start the practical part of the interview by quickly drawing on the whiteboard a simplified diagram of team positions. Then ask the candidate to mark on the board, “what do you consider to be your 5 start areas”.

The purpose of this question is to confirm whether the candidate’s primary areas of experience & skills (according to themselves) corresponds with the role that is to be filled. For example, if this was a front-end developer’s role, but they place their stars against the back-end & database, then they are probably not the best-fit candidate for this particular role; however, they may be better suited for that back-end role that you also have to fill, so be prepared to adapt the interview’s focus accordingly. If the candidate marks almost every area as their top skills, then potentially they could have an overinflated valuation of their own abilities; however, they may turn out to have good coverage of several roles. … And thus, be of great future benefit to the project, and to The Team (as well as to the performing organization).

Another purpose of this question is to make it evident that this is not going to be the typical question & interview. … “So better adapt to the situation.”

4.. Meet some members of The Team. … At this point, bring into the interview a couple / few of the senior implementers from The Team (or associated project teams) to participate as was pre-arranged. Preferably have a mix of ethnicities (as is representative of The Team’s / organization’s makeup), and briefly have each co-interviewer introduce themselves to the candidate.

The purpose of this phase of the interview is to see how the candidate interacts sociably with their potential fellow team members.

5.. Opening design question. … Without giving a verbal foundation to the next scenario, as the interviewing manager, clean the skills-start drawing off of the whiteboard (having given the co-interviewers sufficient time to see what the candidate considers to be their primary skills), and then launch into,

“I have this great idea, I don’t think it has ever been done before.” … And, draw a starting sketch for a system in your company’s field of endeavor.

“It’s an online website where people can buy & sell anything for either a fixed price or as a bidding auction that is publicly viewable.” … Thus, having verbally described a very well-known global ecommerce auction site.

NOTE: For a hardware based role, this opening scenario could be a mobile phone or television device. For a systems engineer, a telephone or TV network. That is, pick a scenario that does not require specific technical knowledge of the subject matter; rather, something that can be extrapolated “on-the-fly” based on a general principle of, “so how would I break that down.”.

Having completed your part of the drawing, hand the candidate the whiteboard marker and ask them to fill-in their design of the proposed system.

The outcome of this request is that, the candidate will either;

Remain fixed in their seat and try to verbally “ummm & ahhh” an answer, or

They will get up and chicken-scratch a couple of boxes & words, but not produce any interconnected thing (that would commit them to a possible wrong answer), nor will they be able to verbalize the formation of a solution. … Or,

They will draw a high-level system with summation blocks, and quickly build-up an overview map to their solution, or

They will dive down into detailed boxes of sub-components that makeup portions of the system, but they won’t necessarily have enough time to draw the entire solution.

The purpose of this question, other than to get the candidate to (literally) “think on their feet”, is to provide the candidate with the opportunity to demonstrate that they can come up with an implementer’s solution. Additionally, this question determines whether the candidate is a high-level or detailed thinker; as certain roles within The Team, such as business analyst and tester, will tend towards different styles of thinking. … “Don’t build The Team with only one type of thinker.”

6.. Expanding on their solution. … Invite the co-interviewers to ask questions about the candidate’s whiteboard design. … As the interviewing manager, watch for how the candidate interacts with their potential teammates’ questioning.

7.. Changing their design. … At this point, change the scenario by saying that,

“The website’s operator also wants to be able to sell their own products and to be able to ship out customer purchased inventory, so how will this requirement change the design”.

The purpose of this question is to determine how (and if) the candidate adapts their solution to requested changes, and how do they react to the associated questions & suggestions from their potential teammates.

NOTE: The important thing is not the technical correctness of the candidate’s solution; but rather, how they drew it, were they able to explain it, how did they interact with their potential teammates’ questions & suggestions, and how adaptable were they to changing their design.

With that first design question answered, as the interviewing manager, wipe the board clean. While cleaning the board don’t say anything, as the silence and time taken to clean the board will probably mean that the candidate returns to their seat, and thus to a certain seating body position. Is the candidates seating position the same position as their earlier defensive (crossed arms / legs / hands) or are they sitting more openly?

8.. Project targeted design question. … Repeat the process of the previous question, but this time make the scenario as close as possible to the project’s subject matter (taking into consideration any business confidentiality & security clearance issues).

The purpose of this question is to evaluate the candidate’s expertise in the industry & technologies related to the project. This will also give the co-interviewers more opportunity to interact with their potential new team member. So, let your co-interviewers do most of the questioning & suggesting during this stage.

NOTE: The technical viability of the candidate’s solution is of importance here. And, especially of interest is how well that the candidate can integrate their potential teammates’ questions & suggestions into the drawn solution.

9.. Technical questions. … The targeted design question would then be followed up with specific technical questions from the participating implementers, preferably one question from each. For example, a coding question related to “when would you use such-n-such and when would you use so-n-so”.

These questions should be of sufficient technical difficulty to test the candidate’s knowledge & capabilities; however, these questions should not be intended to technically belittle and/or intimidate the candidate into feeling inferior to the questioning implementer (which could mean you, as the project’s manager, could have a pending team problem with this interviewing questioner).

10.. Difficult technical question. … If the co-interviewing implementers can pre-devise a question that candidates are likely to not know straight away, but have to figure out (and “dig themselves out”) then this could be highly beneficial to determining whether the candidate is “a fighter” who during times of project difficulty will battle on through adversity.

11. Huddle voting. … Once all of the technical questions are complete, ask the candidate to excuse you all, as the invited implementers “need to leave and get back to working on the project”. The interviewing manager quickly departs with the implementers, and holds a very fast-huddle (possibly with the representatives of HR and senior management) out-of-sight of the candidate, and individually verbally vote YES:NO on the “general acceptance” of that particular candidate progressing through to the next round of interviews. After tallying the votes, if there were a combination of YES and NO votes, then any NO voters would give a very-very short summation as to why NOT. Keep this verbal voting very-very short, no longer than 5 minutes; and, it should never turn into a debate, as this debate can happen later. While this YES:NO voting is only a “gut feel” evaluation of the candidate, often there will be a consistency of reasons as to why NOT. Hence, if the candidate has collected a majority of NO votes than most probably this candidate is not the best-fit addition to the Project Implementation Team (according to The Team member’s & yourself).

“But, what happens when The Team’s representatives vote NO, but it turns out that HR / senior management think YES, and vice versa?”

12.. Candidate questions in reverse. … As the interviewing manager, return as quickly as possible to the interview location, and excuse the delay. This delay should have given the candidate time to think over the situation and come up with questions to ask. Inquire whether the candidate has any questions about the role, the project, and the organization at large.

13.. Selling the organization. … If the candidate received predominately YES votes, then this is the time for the interviewing manager to sell the role, the project, and the organization to the “desirable” candidate. Conversely, if the candidate received a clear majority of NO votes, then keep the remaining conversation short & sweet.

Remember that, while you are evaluating the candidate to hire, the candidate in turn is deciding if they really do want to work at this organization.

14.. Explain what happens next. … Explain the process going forwards from here.

After the candidate has departed, then.

15.. Debate the YES candidates. … The interview participants (including HR / senior management) should come together to debate the merits of those YES candidates.

16.. Job offer or the final decision. … The chosen YES candidate would then be either offered the job or invited to a final round interview with senior management.

17.. Integration into The Team. … Sometime later, the chosen candidate will start work at the performing organization, and subsequently they need to be integrated into the Project Implementation Team.

4.3. Construction A Team

4.3.1. Team Dynamics & Team Relationships

As with any group of individuals that comes together to form “a team”, be it a Project Implementation Team, a sporting team, a social club, the resultant team will naturally go through five distinct stages of relationship development;

1.. FORMING – is when independent persons come together as assigned team members and learn about the project, learn about their individuals roles & responsibilities within The Team, and learn about each other. As with any relationship, the Forming Stage is when people start to reveal themselves; i.e. their values, beliefs, priorities, abilities, and their individual quirkiness.

If a pre-established Project Implementation Team has lots of new people added (in a very short amount of time), or there is a marked change in the workplace location, then this Forming Stage may reoccur, in what was, a previously performing team.

DO NOT expect a great deal of productivity in producing project deliverables during the Forming Stage, because The Team will be relatively dis-functional as they act as individuals trying to be accepted, and determining their position within the group, i.e. who is who within The Team, and the shaping of a “pecking order”.

2.. STORMING – is when The Team members to “feel” their way around each other and around the project in general.

Differences in team roles & responsibilities will become clearer, and these will be formally & informally agreed upon by The Team members. Differences in opinions, perspectives, and ideas will be raised, considered, debated (argued over), and the “better” ones will be acted upon.

This is also when the ground rules for expected & acceptable behavior will formally & informally be established. Differences here could potentially result in highly detrimental conflict between team members, and (in a worst case) conflict with the Project Manager and with other project stakeholders. To resolve any such conflicts will require the guiding hand of the Project Manager, and the maturity of the Project Team members to communicate openly with each other.

Unless The Team members’ start to collaborate, compromise, and their self-interests converge, then the Storming Stage can be a very long dark miserable journey for some or all of the people that are involved with the project.

DO NOT expect a great deal of productivity in producing project deliverables at this Storming Stage. Instead, concentrate on the constructive resolution of interpersonal conflicts.

The Storming Stage is when the Project Manager’s “humanities skills” need to come to the fore as; a communicator, a listener, a negotiator, an influencer, a conflict resolver, a problem solver, a planner, an organizer, a delegator, a motivator, and a leader.

This Storming Stage is also when the Project Manager’s leadership style (as authoritarian, participator, and laissez-faire, or combination thereof) will greatly influence the long-term resolution of any such conflicts.

3.. NORMING – by this stage, each member of The Team should have established their (formal & informal) position within the group and know what is their individual roles & responsibilities.

Hopefully by now; internal conflicts have subsided to the occasional misunderstanding, productivity should have increased significantly when compared to the earlier stages, and cooperation between The Team members should have become the norm.

4.. PERFORMING – by this stage, The Team should have established (formal & informal) cooperative working relationships between the various team members, as they work their way through the Executing Phase of the project’s life cycle.

The Team should now be functioning as a cooperative & collaborative team; resolving their own internal problems & conflicts, having understood each other’s strengths – weakness – values – beliefs – priorities, and with the common goal of successfully completing “their project”.

An effective / high-performing team would spend the majority of their time in the Performing Stage; whereas, an ineffectual / under-performing team could spend a large proportion of their time bouncing back & forth between the Storming, Norming, and Performing Stages.

Then of course, at some point in the future.

ADJOURNING – by this stage, the project is (hopefully) concluding and the Project Implementation Team starts to be disbanded. The Team members come to the realization that they will not be working together with some or all of these people again, which could result in a feeling of lost mateship, and insecurity about what is next for them (as a group and as individuals).

Which brings us to the next rule of “Adaptive & Proactive” SDLC Project Management

RULE 37: Forming – Storming – Norming – Performing – Adjourning is the natural sequence of team life. Where one cannot jump from infancy to adulthood without going through the awkwardness and traumas of adolescence.

4.3.2. Team Work and Team Cohesion

When you were a kid and played Saturday team sports, what made your side a winner, or more specifically, what made your team enjoyable to play with?

So, what is different now that you are all grown-up as an adult at work, instead of a kid playing in the park?

Though, you as the project’s manager will now play the role of coach, not captain.

Transforming “a team” into an “A-Team”

For “a team” of individuals to be transformed into an effective & efficient “A-Team”, then the project’ manager needs to facilitate a working environment that:

1. Gives a common sense of purpose, and emphasizes a commitment & dedication to the common objectives. … Of, delivering the project with the agreed [Scope], by the agreed [Time], within the agreed [Cost] budget, and with the agreed level of [Quality].

2. Encourages open, effective and efficient communications between The Team members, with the Project Manager, and with the project’s other stakeholders.

3. Instils trust & mutual respect between The Team members, with the Project Manager, and with the project’s other stakeholders.

4. Formulates a set of formal & informal ground rules defining the expected & acceptable behavior for The Team members, for the Project Manager, and for the project’s other stakeholders.

5. Establishes informal & formally accepted ways to constructively resolve internal & external conflicts between the Project Team members, with the Project Manager, and with the project’s other stakeholders.

6. Outlines informal & formally accepted ways that decisions will be made by the Project Team members (technical) and by the Project Manager (interpersonal).

7. Encourages The Team to solve their own problems in a collaborative manner, before escalating these issues to higher management.

8. Tries to inspire & motivate The Team to achieve higher performances.

9. Organizes and arranges for guidance & support from the senior management at the performing organization.

10. Provides timely feedback & constructive criticism on The Team’s performance, as well as relaying feedback from the primary stakeholders.

11. Ensures that there is a common identity for The Team, even giving the project an identifying name (if one is not already being used), not an acronym-ized number.

12. Encourages a sense of belonging. Ensures that all team members participate, are given “a fair go”, have their individual input sort, heard, and where relevant accepted.

13. Tries to co-locate the project’s team members. If this is not physically possible then tries to arrange for virtualized co-location to be established via the utilization of telecommunications technologies. Such as; Virtual Private Network (VPN), shared screen desktops, shared digital whiteboards, Voice Over The Internet (VOIP), video conferencing, instant messaging – text chat, shared storage of files … etc.

14. Ensures that appropriate rewards & recognition are obtained for good performance, as a whole team and also for those individual standout doers.

15. Tries to provide The Team (and its individual members) with work that is challenging, and provides opportunities for each team member’s career advancement & knowledge growth. … “And, not just the advancement of the manager at The Team’s expense. … to rise upon the crushed backs of others.”

16. Tries to maintain a friendly, healthy, & sociable atmosphere for all members of The Team. … “Including the quiet, the withdrawn and the newbies.”

17. Removes those barriers that prevent The Team from achieving the project’s objectives.

SDLC Team Building … “welcome to the legion”

Now that the individual members of The Team have been recruited, the next concern is how to mold this body of people into a collaborative & cooperative team? … While at the same time, resulting in productivity returns for the performing organization.

This sort of problem should not be prevalent for a pre-existing Project Implementation Team that has been working together in its current form for some time, nor should this be much of a problem for a pre-existing team that has to absorb a couple of new team members. Because there should, by now, be well established team dynamics as to the implementation processes & procedures, and the work practices & behavioral expectations that are carried over from the Team’s previous projects.

However, what about when The Team is made-up of persons who have never worked together before, or a pre-existing team that is performing way below expectations?

Break Them Down and Build Them Up

If you were building a fighting force which composed of recruits with different nationalities, different ethnicities, different previous military training, and different levels of combat experience, then the first thing that you would do is to break each individual recruit down to a common baseline, and then build them up together as a cooperative & collaborative unit (aka, “A-Team”).

So, how to do this for an SDLC Project Implementation Team?

1.. Co-locate The Team. … Based on geographical, logistical, and political limitations, try to have as many members of the Project Implementation Team physically located together in the same office / floor space. The primary advantage of co-location is that, it’s so much easier to get people to start communicating with each other if they can simply turn around in their chair and “talk face-to-face” with the person that they need to exchange information with. Additionally, try to provide them with a few portable whiteboards so that they can collaboratively discuss their ideas.

2.. Give them a common problem to resolve. … When a Project Implementation Team is newly put together, then most probably the project has just started; hence, the project could still be in the SDLC phases of either Initiation or Planning. With the project having not long been underway, this provides an excellent opportunity to have the individual members of The Team work together in small groups to understand the project’s objectives, requirements, and deliverables. … And, to learn what are the “needs & wants” of the project’s primary stakeholders.

With a Project Implementation Team, ideally composed of 6 to 7 members, amongst sub-groups of pairs / trios of these individual team members, breakup the following activities; (1) Customer Requirements updates / draft of the Detailed Specifications, (2) preliminary architectural design concepts, and (3) preliminary mock-up concepts. Get each sub-group to work on their given part for exactly ONE DAY, before they have to handover their work to another of the sub-groups to continue on with.

Remember that this is still very early in the project’s lifecycle, possibly this is only the first week of The Team being put together as a group of individuals. … And, various persons composing this group will have differences in skill levels & past experiences (as either senior, middle, junior, or a recent graduate implementer).

The purpose of the ONE DAY swap over and the parting up on Project Initiation is to:

Get individual team members to work together as pairs or trios, so as to cooperatively build a common understanding of what the project is all about.

For each sub-group to communicate with each other at the handover.

For every person in The Team to obtain a common exploratory introduction to the project’s technological basis, and to get communal design ideas flowing.

For every person in The Team to hopefully, interact with each other.

NOTE: It is very important that the swap over occurs after one ONE DAY’s duration, ideally swapping straight after lunch. The reason being that, in one day a fair amount of work can be done by the pair / trio, but not too much work being completed, so that other sub-groups are able to keep up and make changes & suggestions to each partition of work. Thereby, providing a catalyst to the Forming Stage of learning about the project and learning about each other.

3.. Establish points of contact. … During this first week of the project, if possible, don’t declare someone as the “team leader”; instead, ask for people within the group to volunteer to be a “Point Of Contact” (POC) for specific partitions of understanding the project. For example, someone to take responsibility for the preliminary architectural design concepts, and someone to take responsibility for the GUI mock-up concepts.

Let the natural leader arise, and then appoint the most appropriate POC as The Team leader. By doing it this way, team members will have a good feeling as to who is better suited to technically lead this particular project. … And, this can greatly reduce resentment within The Team because “so-n-so” was appointed team leader.

NOTE: Up to this point, the (hidden) objective has been to convert each member of The Team from thinking & speaking in terms of, “I can do this, you can do that”, across to a mindset of “WE CAN do it”. … And, this literally does mean how they use the words, “we” , “you”, “they”, and “I”; because, the moment that each one of them starts using the term “we” when referring to the project, then the more likely it is that they are seeing themselves as “A-Team” and not as individual members of a body of people (which happens to be called, “a team”).

Thereby, encouraging “team buy-in” which builds team ownership of the project, which promotes self-organization within The Team; instead of, the perceived drudgery of being assigned to work on “someone else’s project”. This type of “team buy-in” will potentially give the project’s manager more time to concentrate on the stakeholder’s needs, the risks confronting the project, and the necessitated changes to the project … And, allow the Project Manager to deal with other projects that they happen to be simultaneously allocated.

WARNING: watch out for The Team member who uses their senior implementor’s job title and/or says things like, “LISTEN HERE, I’VE GOT ## years of experience in this field” to push their point of view, so as to win a team discussion; as this person is potentially not going to be much of a team player. This person could in fact by very detrimental to The Team’s cohesion & morale, because they stifle others willingness to contribute.

As the project’s manager, I would recommend that you privately take this person to the side, and “have a talk” about the impact that their actions are having on The Team as a cohesive unit. … And inform them that, “at this stage, a perfectly correct technical solution is not as important as everyone understanding what the project is about, and team participation.”

A Common Foundation For Daily Stand-up Meetings … for Agile, Iterative, and Waterfall based projects

During this first week of The Team being together, I would recommend that the Project Manager take on the role of the Daily Stand-up Meeting Master; so as to establish team oriented work practices & behavioral expectations, see [Section 3.5.6].

It’s our scrum, and we will run it how? … For the first daily stand-up meeting (henceforth to be held each work day), as the project’s manager, establish by demonstration the format for all future stand-up meetings, that in a circular fashion, each team member will summarize:

1.. What did I achieve during the last 12 working hours (i.e. yesterday and the time prior to holding today’s stand-up meeting).

… Then, it is the next team member’s turn, until the circle is complete.

2.. What is “blocking” me from doing my work in the coming 12 working hours, have I identified any ˂risks˃ to the sprint’s timely completion, and do I need help?

… Then, it is the next team member’s turn, until the circle is complete.

The project’s manager, as the (first day’s) Daily Stand-up Meeting Master, should after each team member has stated a blocking issue / raised a concern / asked for help, then bullet-point this on the whiteboard that is present in the meeting area; but, DO NOT discuss / resolve this point now, just keep the circular flow going. If a team member(s) diverges off topic or digresses into a discussion then, as the Daily Stand-up Meeting Master, stop them there and remind the entire team that such discussions are to be done independently with only those people who really need to be involved.

At the (second day’s) Stand-up Meeting, as the project’s manager, select one of the junior team members (e.g. the graduate) to be today’s Stand-up Meeting Master, and when they happen to miss a step (in the previous day’s demonstrated process) then hint them through that bit of the process.

Do the same thing for the next day’s stand-up meeting, until everyone in The Team should have had a go at being the Daily Stand-up Meeting Master. … Then, the project’s manager should step away from being actively involved / present at each day’s stand-up meeting; so that, The Team is effectively running their own stand-up meetings and self-coordinating their work activities.

The purpose of the demonstration of the Daily Stand-up Meeting process is to:

Establish a common process for all members of The Team to follow, given that, some members will have done it differently at other organizations.

By giving each team member (including the graduates & juniors) a go at being the Daily Stand-up Meeting Master, this will help flatten The Team’s hierarchy from a pyramid structure with the senior members at the top, to something more conducive of a cooperative & collaborative “fellowship”.

Establish a mindset of; … … (1) Recognize & Reassess what happened yesterday,

2.. Reassess & Revise if something different needs to be done,

3.. Plan to Apply what needs to happen for the rest of today and for tomorrow. See [Section 2.5.1] on Project Rescue silently meshing with the project’s routine ‘PLAN – DO – CHECK – ACT’ cycle.

Initiating – Planning – Executing – Closing

“This technique works particularly well for a team of 6 to 7 members, though it works just as well for teams as large as 12 to 14 members. It especially works well, when The Team has a good mix of seniors, middles, juniors, and graduate implementers. … And, it’s highly beneficial when The Team is ethnically diverse, as everyone gets to participate as a meeting input provider and as the occasional meeting chairperson.

However, it may not work out so well with a team that consists predominately of senior implementers, because they could feel that they are being patronized (i.e. treated as though they know nothing).”

NOTE: In the following weeks & months, The Team may decide to revise the format of their Daily Stand-up Meetings; with, for example, The Team leader acting as the meeting’s bullet-point taker and functioning as chairperson who decides whether (The Team agreed) meeting processes & rulers are being abided by.

However, what the project’s manager has to watch out for, is if The Team leader starts remolding The Team structure into a pyramid with themselves at the apex (as the self-appointed “Project Leader”) and not just as the technical lead.

Such restructuring is exemplified by the Daily Stand-up Meeting becoming a platform by which The Team leader does the majority of the talking and doles out each team members work assignments (i.e. micromanaging); hence voiding the Agile practice of The Team deciding the ‘To Do Items’ for the Sprint and that it was supposed to be The Team who choose for themselves what they should work on next.

Subsequently, as a result of pyramid-izing The Team’s structure (combined with the possible formation of a “clique group” within The Team), this can cripple the cohesiveness, cooperativeness, and the collaborative nature of The Team.

“Effectively wiping out all of that effort which went into building an A-Team in the first place. … What you’ve now got is a D-Team that puts in a commendable effort, but finishes last.”

EXAMPLE CASE … Miss reading a “Clique Group” as a strong project team.

WARNING: watch out for the “clique group” | “in-crowd” forming amongst the members of the (large) Project Implementation Team.

Comedy movies portray this type of clique group at its extreme, with the 3 to 5 trendy teens who strut their stuff, and make life a living hell for their “lesser” classmates.

In the SDLC world, this “in group” would be composed of 3 to 5 developers / engineers, probably with The Team leader / senior implementer as the (male or female) equivalent of the queen bee”. Where this “queen bee” (unofficially) structures The Team’s operations so that he/she is at the center, with the “in” team members as the next layer, and those “outer” team members on the fringes. This “queen bee” will also make themselves the sole external representative of the Project Implementation Team, having no immediate second-in-command (else a second with limited power & responsibilities).

In the worst cases, the clique group (more specifically, the “queen bee”) can:

Push out (by isolating / ostracizing) those existing project team members that don’t fit-in with the “in” group’s perceived ideals. … “Bye-bye to whoever asks why.”

Pull in by enticing those implementers that they want for their group, even going as far as directly and/or indirectly undermining other project teams to get that “right” person aboard their team. … “Mini empire building at others’ expense.”

Reserving the “interesting” / “important” tasks for their fellow “in” team members, while distributing the “crappy” / “boring” tasks to those “outer” team members.

At the extreme; considering the project’s manager (and senior management) as outside of their “in” group, and hence (in an attempt to protect their “in” group) are prepared to report mistruths when the project’s scheduled tasks are not going as well as was planned. Though, this “in” group is quite willing to place blame for the project’s failings on those “outer” team members. … “Throw’em under a bus.”

Initially, the morale & work ethic of this “clique group” structured team will appear to be high, and they may for all available evidence by progressing excellently; but, this is a falsehood that will eventually fall apart (the longer that the project goes on), because:

1. Those “outer” team members will silently “want out” as they feel that;

Their potential constructive contribution to the project (and to The Team) is being squandered, and their skills aren’t given the opportunity to be exercised.

They feel discriminated against by only being given the “crappy” tasks to do,

Their future career advancement & knowledge growth with this project (and at the performing organization) is greatly limited to non-existent.

1. Those “in” team members while receiving the benefits of getting the “interesting” work to do, will become overloaded & overworked if / when the project falls behind schedule, as those “outer” team members can’t take on more of the heavy burden because they weren’t “trained for” (previously allocated) those important tasks.

2. The Project Team’s cohesion is predominately via an imposed pecking order, and not via cooperative & collaborative fellowship (aka “mateship”).

3. The Team is being driven forwards by a micromanaging team leader “queen bee” who does not necessarily have access to the strategic understanding of how each project release fits into the “Big Picture” of the performing organization’s plans.

If all does proceed along well with this Project Implementation Team being productive; what happens when the “queen bee” team leader gets promoted into another role, moves to another project, or leaves the performing organization for “greener pastures”?

When the “queen bee” departs (or is promoted), then most probably the cohesion of this “clique group” will disintegrate, The Team will quickly unravel as the “in” team members jostle for position in the power vacuum, and the “outer” team members will become under-utilized as there is no “queen bee” to allocate them work and issue new instructions. … And thus, The Team would be back to an unproductive Storming Stage.

4.4. A People First Manager

4.1. Being A “Humane” Project Manager

For the Storming Stage it was stated that, “it is during this stage when the Project Manager’s humanities skills need to come to the fore as; a communicator, a listener, a negotiator, a influencer, a conflict resolver, a problem solver, a planner & organizer, a delegator, a motivator, and as a leader.” … “But, no longer as an implementer.”

A Communicator

As stated previously, “a project manager will spend a lot of their time communicating in both written and oral forms”. Hence, the Project Manager has to be able to communicate effectively & efficiently with all of the project’s stakeholders, and especially with each member of the Project Implementation Team.

“What did you think the Project Manager was going to do, just sit in their corner office and manage by telepathy? Unfortunately, during mine (and most probably your) career, you will encounter managers, even at very senior levels, who evidently believe in management by telepathy, because they don’t TALK to any of their people subordinates, other than to bark-out the occasional order and (at the top of their voice) verbally reprimand someone for something they did wrong. … Which is often due to that manager having not clearly stated what they wanted them to do.”

A Listener

Communications is bi-directional, where someone is transmitting (telling) while the other party is receiving (listening), then vice versa, and versa vice. While the speaker’s role is to effectively & efficiently transfer the information, the listener’s role is to actively take in the information, and then provide some form of feedback to indicate that the information was received & understood.

Hence, the Project Manager needs to demonstrate that they are an “active listener” who takes in what was said and then (evidently) acts upon this information.

A Negotiator

The reality is that, not every situation can be “win-win” for all of the involved parties; therefore, the Project Manager has to be able to work towards a “compromise solution” that is the best possible outcome for (most if not all of) the involved parties. … And, not just “winner take all” for the limited few.

To be a good negotiator involves:

1. Being a good Listener & Communicator.

2. Trying to understand the situation that is causing the problem. This means trying to “see the situation” from each party’s perspective. … And, not just your own, nor solely that of the performing organization (which can result in some ethical dilemmas).

“You will never understand a person until you have walked a mile in their shoes” and “carried some of their burden upon your own back”, or sung along with them at a karaoke bar.”

1. Determining each party’s (real) “wants” and (real) “needs”.

NOTE “Wants” is the high point of what the party is after.

“Needs” is the low point of what that party will accept to be satisfied.

If all involved parties “needs” are at least being met (in some way) then a “compromise solution” is potentially achievable.

“Greed” is to want more than one could possibly need, solely to satisfy one’s self-interest, irrespective of the detriment to others.

DO NOT discount on Greed from (inexplicably) hindering the negotiation towards an amicable resolution.

1. Concentrating on the issues & concerns of the involved parties; and DO NOT focus on the emotional position that these involved parties are taking; because, by focusing on their issues & concerns, one can obtain a better understanding of their actual “needs” rather than being diverted by their perceived “wants”.

2. Realizing that the involved parties personal characteristics, ethnicity, and cultural background will influence how they will approach any negotiations. … And more importantly, how far will they be prepared to compromise; e.g. “a need to save face”.

3. Ensuring that all involved parties are receiving a “fair deal”; because, if one or more of the involved parties feels that they have been taken unfair advantage of, then the negotiated agreement / arrangement will not last very long. Subsequently, everyone will be dragged back onto more negotiations; however this time round, everyone will probably be in a lot less malleable mood because their hands (i.e. advantages & disadvantages, strengths & weaknesses) will have already been revealed during the previous rounds of negotiations.

4. DO NOT make a concession without at least appearing (in the other party’s opinion) to be giving up something of value; because, this will help form an unwritten obligation for the other party to also give up something of value in return. That is, all negotiations involves some form of bargaining (aka “haggling”).

5. DO NOT be the party who is continually surrendering their “needs & wants” in order to try to “reach a compromise”; because, the other party could soon perceive you as a “pushover”, and thus they are highly likely to continue taking until there is nothing of value left to give.

6. DO NOT over sell your position; because, if you are caught out then you could be perceived as being in a weaker position (than you actually are). As a result of this perception, the other party may think that they themselves are in a stronger position, and consequently they may be a lot less willing to compromise, because they are confident that you will be forced to give in first.

7. Do your homework. … If you’re able to “find out what’s going on behind the scenes” then you will be in better position to understand the why and the how come certain involved parties are negotiating; i.e. their true objectives, their real “needs & wants”, their actual advantages & disadvantages, and their strengths & weaknesses.

An Influencer

A good project manager is able to affect people & events without necessarily being directly involved (hands-on), as though using some magical force. Though, the reality is that, while we would all like to have “super-natural influencing power”, most of us mere mundanes have to make do with the following techniques.

1. Know what you want to accomplish. … You cannot redirect them towards your objectives unless you understand what you are really trying to achieve.

• See your perspective – that is, getting them to understand & acknowledge your view of reality, and that they are going to give their best while working towards your stated objectives.

• Modifying their behavior – that is, getting them to change their behavior, based on your perception of its desirability or undesirability. This is done by using positive enforcement to encourage those desirable behaviors and negative reinforcement to discourage those undesirable behaviors.

“IMHO, if you have to resort to negative reinforcement then you have lost the capability to sustain long-term influence over them.”

1. Know what they “need” and what they “want”. … This is similar to negotiation, you cannot redirect them towards helping you to achieve your objectives unless you understand “what’s in it for” them (i.e. what is in their self-interest).

• Rewards; i.e. self-esteem, self-confidence, a sense of achievement, praise & gratitude from others, recognition & respect.

• Gains; i.e. financial, material, experience, knowledge.

• Safety; i.e. job security, stability of employment, belonging to a group.

Which all relates to Maslow’s Hierarchy Of Needs.

Having determined what their “needs & wants” are, your message can then be better tailored towards matching these; thereby, being able to emphasize “what is in it for them”, rather than “what is in it for me”. In addition, by helping them accomplish their “needs & wants” they are more likely to reciprocate and help you achieve yours.

1. Look, listen, learn, and ask. … How else can you know their “needs & wants” unless you pay attention to what they are saying, and more specifically, what they are not saying? You will also have to observe what work & home life constraints would prevent them from being able to do what you require them to do.

Hence, to be a good influencer requires being a good observer, communicator, and listener.

1. Listen to and be open to counter proposals. … Sometimes to get what you “want”, you will have to re-evaluate & re-adjust your proposal based on their responses, and more specifically, their counter-proposals. Noting that, it is easier to get someone to do what you “want” when they are involved in the decision making. … And, this is especially true when they feel that it was them that made the decision; e.g. the ‘To Do Items’ that are to go into the Sprint Backlog that is to be done by them in the upcoming Agile sprint is selected by The Team members and not the Project Manager.

2. Keep focus. … That is, keep their attention on what you “want” them to do, and get them to commit to a date by when they will do that which they have agreed to do.

However, this is a “two-way-street”, so if you have made a commitment to do something for them then it is advisable that you do exactly that (by when you said it would be done), and thereby creating reciprocal expectations on both parties.

1. Communicate openly, clearly, and confidently. … No one will bend to your will if they do not clearly understand what you are wanting of them; so, confidently inform them of exactly what you “want” (in terms that they will understand).

Be consistent & persistent with the definition of what you “want”; but, choose an appropriate time to reiterate the definition (i.e. not too often to cause annoyance).

And, state it without ambiguity and multiple interpretations. For example; “was that delivery on the 1st of January, or was the delivery on the first working day in January, after the Christmas & New Year holiday break”.

1. Time your criticism. … Occasionally the person you have influenced may not have done exactly what you requested of them, or they may have done it poorly. In such cases, negative feedback will be necessary; however, how this negative feedback is administered will greatly affect how much influence you will be able to exert on them in the future.

A misdirected or inappropriately timed negative feedback (given their situation and their prevailing circumstances) is a sure-fire way to lose their respect and reduce their willingness to give you (the criticizer) that extra bit of effort in the future.

1. Criticize as soon as possible after the event that initiated the criticism.

Though, limit the amount of criticism that is dispensed at any one time or is dispensed over a relatively short period of time, else you will be perceived as someone who cannot be pleased (or worse, you will be perceived as “a bully”).

1. Get straight to the point. … be very clear, precise, and honest about the criticism.

DO NOT waste time “buttering them up”, and

DO NOT skirt around the crux of the issue, “afraid of saying the truth”.

1. Let them respond to the criticism, so that they can “tell their side of the story”, as there may be mitigating circumstances, key information may have been missing, or the situation at the time and the prevailing circumstances may justify why they did what they did.

2. Be calm & clear, because being frustrated, angry, or out-right hostile will only make the criticism’s recipient defensive to whatever you have to say.

3. Be serious the entire time that the criticism is being given. … Because, criticism is NOT a joke; to treat it as such will be interpreted as not showing real concern.

4. Never criticize something that cannot perceivably be changed (i.e. you cannot criticize a cat for not being a dog), or because they didn’t perform as well as a certain other person would have / did.

5. Criticism that can be invested. … That is, if you must criticize someone then do it in a constructive manner, so that the recipient will learn from the experience and not be resentful / defensive.

• Always make sure that you are “actually correct” before unleashing your criticism on someone. Make sure that you have all of the facts and that you understand the particulars of the situation & prevailing circumstances at the time of their supposed wrong doing.

• DO NOT criticize them for dealing with an issue / problem the way that they did if that issue / problem resulted from your own failings to do something about it.

If they made multiple requests of you (as their manager) to perform some action and/or to provide them with the appropriate resources, but you failed to deliver in a timely manner, then it is not appropriate for you to reprimand them for taking the initiative to do what needed to be done to complete their assigned tasks. … And, especially if you told them to, “sort it out for yourself”.

• Never “badmouth” theirs of your predecessor’s performance (i.e. the person who previously did theirs or your role) as this will raise suspicions about what you are currently saying “behind their back” about theirs and others performances.

“Let alone what negative things you’ll be saying about them in the future. And, bad mouthing the departed is a sure-way to lose the respect of those who remain and marks you as a poor manager.”

• Never turn the criticism into a personal attack on their character. Stay with the facts at hand, and be precise with the criticism.

DO NOT deviate off-course into an attack on their personality (or worse their culture, ethnicity, religion, believes, sexuality, or gender).

• Having dispensed the criticism, now make it clear what is expected of them.

• If punishment must be meted out then ensure that this punishment is proportional to the crime that they have committed.

1. Do unto others, as you want them to do unto you. … That is, before you can get someone to do what you “want”, they must at least “tolerate” you and may even “like” you. Because, if you treat them badly, or are unfriendly towards them, then it is highly unlikely that you will get them to voluntarily to do what you want them to do (let alone to the standard that you expect).

“Agreed, if they really dislike you then they will keep putting off doing what you want for as long as they possibly can; and, when they do get around to doing it, they will probably, only put in as much effort as they believe is necessary to make you go away.

There is an old adage that “you catch more flies with honey than with vinegar”, which translates to, it is the tone & attitude of what you say, how you word it, and the use of the words ‘please’ and ‘thank you’ that win your way.”

So the next time that you want to influence others then remember to be:

Polite & diplomatic, courteous & tactful, sociable & friendly, generous & kind, concerned with the plight of others,

Show respect & gratitude,

Given others your undivided attention,

Show appreciation for the others efforts,

Strive to resolve the problem at hand,

Compliment people and praise them when they do a good job,

When possible take the time to give them a helping hand,

When necessary go out of your way to help them out.

But, don’t expect to be a successful long-term influencer, if you are (perceived as):

• Anti-social, snobbish, arrogant, know-it-all,

• Mean, nasty, unkind, insensitive to other people’s predicaments,

• Put people down, belittling, degrading,

• Intimidating, bullying, physically threatening, verbally abusive,

• Back-stabbing, rumor mongering,

• Steals the credit from others, or passes others’ work off as your own,

• Passes the blame onto others, and is prepared to “throw them under a bus”,

• Selfish, show-off, look-at-me attitude,

• Ignorant to others problems,

• Ignorant to the fact that a problem exists, to “ bury your head in the sand”,

• Manage situations by avoidance, and in the worse cases, actively going out of the way to avoid a confronting issue.

DO NOT manipulate others by devious means, because when a person feels that they are being wangled into doing something that they would not normally want to do then they will eventually resent doing such a thing, and they will subsequently be negative / hostile to doing other future things.

DO NOT dictate and reframe from micro-management, because a bit of freedom will help in satisfying their own “needs & wants”.

THEORY … Maslow’s Hierarchy Of Needs. [Ref: Maslow]

Self-Actualization Creativity, problem solving,

achieving ones potential.

Esteem Self-esteem, confidence, achievement,

respect, rewards, recognition,

acknowledgement.

Social Fellowship, friendship, social

activities, interpersonal relationships

Safety Employment, job security, safe work

environment

Physiological Those things required for basic survival

food, shelter, sanitation, clothing

Maslow’s Hierarchy Of Needs.

The techniques that the Project Manager could use, include:

1. Be aware of (cognizant to) each team member’s efforts & contributions towards the project’s objectives; i.e. to know what they are doing and what they have done.

2. Give praise to the relevant team members as soon as possible after they have done a good job. … “The proverbial ‘pat on the back’ can do wonders for a person’s self-esteem and the sense of their work being appreciated.”

3. Provide timely feedback on their performance (and if necessary, constructive criticism).

4. Provide challenging tasks and not just the repetitive boring / “crappy” bits.

5. Provide new, expanded, or different roles & responsibilities.

6. Provide opportunities for individual growth and career advancement.

7. Provide acceptance of their proposals and consideration of their ideas.

8. Ensure that they have a balance between their work life and their home life.

A Motivator

The Project Manager has to be able to get the Project Team members personally committed to delivering the project in accordance with the agreed Acceptance Criteria for [Scope] & [Quality], within the agreed [Time] & [Cost].

To achieve these goals, the Project Manager needs to “motivate” the Project Team members’ individual & combined efforts. So, how does the project’s manager do this?

Well, … it is, the exact same things that motivate you each workday.

To wake up before the dawn to that incessant alarm clock. … To drag yourself out of that nice warm comfy bed. … To have a shower & groom while your eyes are still welded shut. … To apply that sociable face. … To put on that not so comfortable outfit & shoes. … To jealously kiss your partner on the forehead while they get a few minutes more sleep. … To say goodbye, but nor be heard as your youngest one plonks their butt down in front of that big TV screen that you never have the time to watch, as the older one giggles away at something indecipherable that their invisible friend responded with.

To walk to the bus stop or train station in dark miserable weather, to stand like emperor penguins for an hour or more with people squished into your personal space. Alternatively, to listen to advertisement-interrupted senseless breakfast radio as you stare at the stream of glowing red taillights snaking off into the distance as you crawl in traffic from your massively mortgaged little kingdom in the burbs.

To enter that open planned cubical farm of half-height padded grey walls where everyone can see everything you do and hear everything you say. … To sit down in that less than ergonomic chair, surrounded by a bunch of post-it notes and faded photos of when your kids thought you had a relevant opinion.

To finally, sip on that re-boiled pick-me –up in your brown stained “world’s greatest” coffee cup, while having breakfast at your assigned desk, as you are confronted by the daily barrage of unanswered emails.

“That is so depressing. … I think I’ll go get another coffee.”

So, … what motivates you to come to work each day, and give your all for the project’s success? Then repeat this cycle again & again, day after day, for weeks – months – years to come?

Motivating Myth: Financial & Material Gains

Does the hourly thought of coins falling into your piggy bank really motivate you to give your best efforts at work?

Nope, … money, bonuses, and share options are NOT motivators; rather, these are “initiators to action”. That is, if you are currently unemployed or in (what you know is) a grossly underpaying job then money will be a good motivator for you to find a new job. However, when you currently have a relatively secure job that pays you at an acceptable level then money is no longer a motivator; in factuality, payment is an expectation, an inane right (given that daily drudgery of coming to work).

Also, you would probably be paid weekly / fortnightly / monthly, and those bonuses are only handed out at the end of the financial year. Hence, these gains are not directly associated with your daily work efforts; rather, these incentives are determined by the annual / biannual review of your past performance (if and when such reviews do occur). Alas, such gains do not drive you (nor the Project Team members) to give all for the project, let alone give every day your best efforts to the performing organization.

“Oh, and if your project team consists of contractors then they probably won’t get any performance bonus let alone performance reviews. Instead, they are often shown the door when the project is done.”

And, … the Project manager probably won’t have a direct say over what the Project Team members are individually paid, as these people were probably, just assigned to the project.

Hence, financial & material gains are NOT motivating tools in the Project Manager’s arsenal.

“Oh, by the way, word is that there won’t be any pay rises this year (for the majority if not all of the staff), not even an inflation matching CPI increase. Subsequently, the work place will be demotivated for some time to come; and, there will be a few disgruntled employees who will be contemplating looking for work elsewhere, so as to find an employer who is prepared to compensate them appropriately for their efforts.”

Motivating Myth: Rewards & Recognition

Does being rewarded & recognized for yesterday’s performance really spur you (and the Project Team members) to perform today, and tomorrow?

Some companies try to use rewards & recognition, such as “employee of the month” or “most valuable employee”, to stimulate performance. While these maybe acceptable in a competitive work environment such as sales; in an SDLC project environment these “one winner takes all” motivators would in fact be detrimental to the Project Team’s cohesion & morale, because these supposed motivators encourage individual self-interest over teamwork.

Also, with rewards & recognition, the point of application of these supposed motivators is greatly removed from the moment when the performance occurred.

“Oh, and the company rules probably dictate that contractors are not eligible for such rewards & recognition. So, there goes that as a motivating tool for a portion of the Project Team.”

And, … as the Project Manager, you probably can only make recommendations about which project Team members should be considered for such rewards & recognition (which are then doled out later on at some ceremonial get together that is completely disassociated from when that performance actually contributed to the achievement of project success).

Hence, rewards & recognition are NOT motivating tools in the Project Manager’s arsenal; rather, rewards & recognition are “anti-demotivating” “thank you” tools, for the performing organization to deploy (not for the Project Manager to utilize).

Motivating Myth: Threats, Intimidation, and Punishment

“Seriously ?? … Threats, intimidation, and punishment, … as a motivator ??”

Threats, intimidation, and punishment (including across-the-board harsh / vindictive performance reviews) will only work as motivating tools for an SDLC environment where the recipient implementers “have nowhere else to go”, due to:

Job insecurity – of high unemployment rates, incumbent age discrimination, and the financial realities of “having this crappy job, is better than having no job at all”.

Lifetime commitment – the recipient has been with that particular performing organization for so many years, that to leave now would be tantamount to getting a divorce (having worked at this place for longer than they have actually been married).

Home life priority – work strategically positioned for ease of home life circumstances.

Personality type – the recipient has a subservient “drone like” demeanour.

Also, … threats, intimidation, and punishment are only viable in response to already existing poor performance; to use such “motivators” prior to the actual performance (other than in response to pre-existing poor results) is equivalent to a pre-emptive strike.

While the contracted business arrangement between the customer organization and the performing organization may include penalty clauses related to liquidated damages and performance bonds as guarantee; the performing organization should have incorporated into the contracted price a contingency for such penalizing situations, and potentially the performing organization would be entitled to performance bonuses.

However, for mere implementers then such threats, intimidation and punishment only serve as encouragement to leave as soon as possible. … And, if such management behavior results in work related stress being expressed at home, then that implementer’s (misery affected) partner may also be encouraging them to leave. Subsequently, there could be a contagion of staff resignations, as an ever shrinking core of SDLC implementers become more & more demoralized; which can lead to the constant “churning” of staff.

“IMHO, if there is a yearly Resignation Turnover Rate exceeding 15% for an SDLC group, then the performing organization has got real (pending) problems with technical knowledge and intellectual property drain.

If the SDLC personnel’s Resignation Turnover Rate is at 25-33% levels (i.e. a quarter to a third of the implementers are changing each year), and given that it takes at least 6 months for their replacement to get up to speed to be a truly self-sufficient implementer, then productivity is going to take a major down turn or remain appalling. Any Resignation Turnover Rate greater than these levels, is organizational suicide.

Mathematically, this SDLC group could have a half-life of only of coupe of years (where more than 50% of the staff have changed), and people only stay for a year and a bit, as though serving a Tour Of Duty in a war zone. Subsequently, the “old timer” implementers won’t bother properly training and mentoring the newbie because they or them won’t be around long enough to justify the effort involved.

Consequently over time, those implementers who do remain will progressively be transformed into involuntary “yes men” “drones” who no longer possess the creative intellectual spark to drive the SDLC group forwards to higher performance. As a result, the performance levels and morale of this group will baseline to a plateau of stagnancy.”

Such high Yearly Resignation Turnover Rates of SDLC implementers is an indicator that the performing organization has been inflicted by a sociopath manager(s) somewhere up the management hierarchy; subsequently, the SDLC group won’t be able to reach anywhere near full potential of effective & efficient productivity. … And, morale could be so low that, most probably, past & present staff will be “bad mouthing” the company; hence, the organization will garner the reputation as “a place to steer clear of, unless you’re really desperate to get work, and then, only as a short term stay until you find a better job”. … “At which point, try delivering quality of projects on time.”

Hence threats, intimidation, and punishment are motivating tools that SHOULD NEVER be in the Project Manager’s arsenal. … “Unless you’re a narcissistic psychopath.”

Motivating Tools

To motivate the Project Team, the project’s manager needs to create a work environment that is conducive to each project team member’s intrinsic & extrinsic motivations; while simultaneously, minimizing those demotivating factors.

Intrinsic motivation – is generated within the individual person due to the type of work that they are performing; i.e. a sense of achievement & worthwhileness, plus a feeling of personal growth.

Extrinsic motivation – is generated externally to the individual person and includes such motivators as; financial & material gains, rewards & recognition, competition, as well as threats, intimidation, and punishment.

Hygiene factors – are not motivators as such, but if these factors are not present then the work environment would be less “healthy”; i.e. a less enjoyable place to work.

Also referred to as “demotivating factors”. … “I hate this job.”

As described previously, these extrinsic motivators are not tools that the Project Manager can effectively utilize; because, these are administered after the Project Team member’s performance has occurred. Hence, the Project Manager needs to concentrate more on those intrinsic motivators that are closer to the time when the work activities are performed, or (even better), prior to such work activities being performed; thereby, being beneficial to the project’s quality assurance processes.

To intrinsically motivate the Project Team, the project’s management needs to establish a work environment that encourages (and is a catalyst for); job satisfaction & self-esteem, a sense of accomplishment & achievement, a sense of belonging, and a feeling of kinship.

While the Project Manager deals predominately with the intrinsic motivators, the project’s primary stakeholders should be dealing with those extrinsic motivators. Whereas everyone; including the Project Manager, the primary stakeholders, and the Project Team needs to deal with those hygiene factors.

MOTIVATION … “Getting More Without Punishment & Pay”

So how to motivate the members of the Project Team without resorting to bringing out the punishment stick or bribing them to work harder?

Bi-directional Trust & Respect … A manager who trusts their people to get things done and respects that (when possible) their people will do what they think is the right thing to do; while these people can trust their manager will “protect their backs” if & when things do go wrong.

Boundless Contribution … A manager who allows their people to contribute beyond the predefined boundaries of their job roles; which means empowering them with varied – interesting – challenging work and giving them the authorization & responsibility to perform such work, thereby providing them with opportunities for their own personal growth, a sense of achievement, and career advancement.

Recognition – Timely Feedback – Constructive Criticism … A manager who is aware of and actually recognizes their people’s efforts & contributions, gives public praise for a job well done, provides timely feedback on their performance, and provides constructive criticism on that which they actually have the opportunity to improve.

Team Participation & Involvement … A manager who is conducive to a participatory team environment where all members are given equal opportunity to contribute to the resolution of a common goal / problem / the objectives at hand.

However, which motivators will produce the best results will depend on the characteristics of the individual that the motivator is being applied to; because, their personality traits, ethnical & cultural background, their age (i.e. maturity), and where they currently are at that stage in their life will greatly influence the effectiveness. Consider “Maslow’s Hierarchy Of Needs” of Physiological – Safety – Social – Esteem – Self Actualization, [Figure 82], … now consider your own personal situation & prevailing circumstances. … So, what arrangement and weighting of these will influence your personal motivation to give your all for the project and for The Team, right now ??

A Team Builder

When recruiting the Project Team, … “it is very important that the Project Manager strive to build a cooperative & collaborative Project Implementation Team; as it is not the Project Manager, but rather The Team who transform the project from mental concepts into physical deliverables”.

Hence, the success of the project is very much dependent on The Teamwork that can be (and is) generated within The Team; and therefore, how well the project’s manager encourages & fosters an environment that emphasizes team-building & team-work over individual self-interest & self-gratification.

While the project can have a pedantically detailed plan, lots of [Time] on hand, cash in the bank, an abundance of [Resources], and the best available [People] as team members; nevertheless, without the “right blend” of people to execute The Plan, then the project has at best a 50-50 chance of success (i.e. to not perform optimally as is desired / expected).

At this point, this book could detail “team inventory” [ref: Meredith Belbin] and describe the nine team roles; i.e. plant, resource investigator, coordinator, shaper, monitor evaluator, team worker, implementer, completer / finisher, and specialist. … But, for the majority of cases, as the project’s manager, you will most probably “just have to make do” with those persons who have been assigned to the project by the performing organization’s senior management (possibly based on who was / is available at the time).

Additionally, if you were involved with the recruitment of new people to work on the project, then, … unless you did some “stand-u & show us what you can do” SDLC interviewing, see [Section 4.2.3.], … then most probably you won’t have encountered the recruit’s true character; but rather, their “spit-n-polish” persona that they presented during the job interview. Therefore, let’s forgo this team inventory theory, and instead concentrate on the apparent personality of The Team members that are at hand. That is, “just make do with what you’ve got”, not who is desirable to have.

Ideally the Project Team should be built with people that have different personalities types; because, while a team of highly intellectual clones (or malleable worker drones) may be successful in the short term, this grouping will lack the spark to continually generate new ideas & initiatives (nor continue to be productive). Also, after a while this work place could feel stale, monotonous, and void of recognizable human life.

“Working in a cathedral of monotone faced zombies and drones.”

The successful project team needs a blend of both technical minded and socially adept individuals; as a good mix of both types will result in a project team that has good morale, spirit, work ethic, mateship, and commitment to each other (finish “their project”).

Which brings us to the next rule of “Adaptive & Proactive” SDLC Project Management

RULE 38: It is not who has the most talented individuals in their team; but rather, who is able to get these individuals to function as a cohesive unit … as an A-Team who strives to win.

RULE 38A: Project team morale is that elusive ingredient that can give the project continued drive (and faith in eventual success) when the current situation and prevailing circumstances have turned bleak.

Motivation & Team Building … “a poor man’s bonding sessions”

It is a simple matter of economic reality that most small (to medium) sized organizations don’t have the budget (nor the time) available for formalized team building activities that are targeted specifically at “team bonding” and improving “group dynamics”. Hence, it is not feasible for members of staff to go offsite for sessions with “Human Relationship Consultants” to “workshop” The Team building experience.

Instead, The Team building will come down to the Project Manager, the Project Team members, and senior management taking it upon themselves to encourage & foster a friendly – sociable – cooperative – collaborative – collaborative work environmental.

This makeshift team building could be as simple as:

• Lunch time chats (away from ones’ assigned desks) talking about anything other than work related matters. Even better, getting out of the office, in small groups for a sit down lunch at the local diner / café / park bench.

• A coffee break discussion about the latest goings on of some TV show, that movie which some have and have not seen, or that internet video cat sensation.

• Stirring each other over one’s obsessive devotion to a make of car / sporting team / operating system / mobile phone brand; i.e. in jest stirring of each other.

• Banter about the kids, what they did, and the last in-thing which you just don’t get.

• Friday afternoon (non-monetary) betting on how regional / national sporting team will fair that coming weekend, combined with the obligatory Monday morning expert analysis of the results and the ribbing thereof (until next weekend’s round).

• Going off for a walk, playing some sports, … just having fun together as a group.

• It could be (after work – off of the corporate computer network) kicking back as a “clan” clashing swords with Orcs, launching that counter-strike to recapture the battlefield’s high ground, or joining forces to holdout against suicide waves of rampaging alien hordes (or those irks from accounting).

• And, encouraging others (especially the newbie and the sly ones) to join in.

A Conflict Resolver

Whenever two or more people are involved with something, there will always be some form of conflict. Such conflict will generally stem from the involved parties “needs & wants” (for resources / territory / priority), for acceptance of their opinions, over principles or believes, due to poor communications, misinterpretations, or misunderstandings.

Surprisingly, often the simplest solution to conflict resolution is to “listen” to the involved parties” airing their grievances”, then “communicating” back to them your interpretation of what they have said, and asking “questions” about the situation & circumstances of the issues. Sometimes, this is sufficient to initiate the Conflict Resolution Process.

Let each involved party state their case without being interrupted, unless it is to politely tap them back on course because they have gone off topic or they are going over the same point again & again.

Ensure that the “discussion” concentrates specifically on the current issues at hand and does not degenerate into personal attacks, nor encompasses ancient history nor misdeeds from the past.

Show some indication to all of the involved parties that you understand what they have said (even if you happen to disagree with their point of view); e.g., the occasional head nod, and “hmm, yes, I see”. Then ask them how this issue can be resolved to their satisfaction; thereby establishing a starting point for negotiations.

The solution for how to satisfactorily resolve the issue may now be apparent, given that all parties have had the opportunity to express their viewpoints, and state their case.

Thus, conflict resolution has to be undertaken in an open constructive manner, using those techniques that were previously laid out for influencing & negotiating; as well as, listening & communicating.

THEORY … Conflict Resolution Techniques. [Ref: Thomas & Kilmann]

1. Withdrawing | Avoiding – is where one of the conflicting parties retreats from an existing or potential conflict / disagreement. This technique deploys tactics such as; not bringing up the issue, sweeping the issue aside by changing the subject, or saying it will be dealt with later on (though fully intending not to do so). These tactics can thus be used to; postpone the conflict until one is better prepared to handle the situation, cool-off the involved parties (especially the aggressor), or simply to not have to deal with such a (trivial) issue.

If the Withdrawing | Avoiding technique is used inappropriately or continually then this can result in bottled up tensions, and conflicts simmering away beneath the surface of the relationships. … And, this could very well boilover into a larger conflict than that which was being avoided in the first place.

1. Smoothing | Accommodating – is where one of the conflicting parties forgoes their own “needs & wants” so as to oblige the other conflicting parties. This technique deploys the tactics of modifying or completely changing ones position (or opinion) to coincide with the other parties; possibly aligning with the consensus, the subject matter expert, the superior rank, or the dominant personality.

If the Smoothing |Accommodating technique is used inappropriately or continually then this can result in the obliging party being seen as “a weak pushover”. In addition, this technique may conceal the underlying cause of the conflict between the involved parties. This technique could also be used as an extension of the Withdrawing | Avoiding technique.

1. Collaborating – is where the conflicting parties work together to find a “win – win” resolution that is “mutually beneficial” to the involved parties. This technique involves; having open discussions about the conflict and its impacts on their respective objectives, with the involved parties contributing to the discussion, the proposing of alternative solutions, and finally agreement on the chosen solution.

If the Collaborating technique is used inappropriately or continually then this can result in the involved parties being bogged down in “design by committee” which may not be able to achieve much relative productivity in the available time. … And, this could result in a solution that is a compromise of political diplomacy versus practical viability.

1. Compromising – is where the conflicting parties work together to find a “no lose – no win” resolution that is “mutually satisfactory” to all concerned. This technique involves; discussing the problem (possibly with the involvement of a neutral third party acting as mediator) where each party given up some portion of their “needs & wants”, bargaining & negotiating occurs between the involved parties; and finally the parties come to an amicable agreement / arrangement / understanding.

This compromising technique should be used when the conflict is escalating but there is still time to come to a mutually satisfactory resolution.

1. Forcing | Dominating | Competition – is where one or more of the conflicting parties adopts an assertive posture where their “needs & wants” are placed ahead of the other parties; potentially to the other parties’ detriment due to a “win – lose” resolution. This technique is based on capitalizing one’s; authoritarian position within the management hierarchy (or within the Project Team), influence within the organization, dominance in the field/market, superior subject-matter knowledge, or simply by aggressive behavior.

If the Forcing | Dominating |Competition technique is used inappropriately or continually then this can result in animosity between the conflicting parties, resentment by the “losing” parties, a feeling of superiority & dominance by the “winning” parties, a feeling of disempowerment by the “losing” parties, reduction in morale & motivation, and an antagonistic atmosphere amongst the involved parties.

The Forcing | Dominating | Competition technique should only be used to get things moving when a quick decision is essential, such as during a crisis event.

A Problem Solver

The Project Manager should live to solve problems, either by themselves or via the intermediaries of other people.

If you’ve come from a technical implementer’s background then, most probably you’re already adept at problem solving, and hence you don’t have much to learn here. … How, ever, there is a major difference now that you are the project’s manager; whereas, previously you would solve inanimate technical problems using your copious amounts of technical “hard skills” (i.e. analytical, mathematical, mechanical, logical experience), instead you will have to solve issues that are related to human beings and their inter-relationships. Thus, utilizing your humanities “soft skills” as a communicator, listener, negotiator, influencer, motivator, and conflict resolver.

As with the solving of technical problems, an ad-hoc solution for people problems will often generate other unforeseen problems, in some kind of ripple effect. A way to alleviate this is, to employ a “PLAN – DO – CHECK – ACT” problem solving strategy of:

1.. Determine the real cause of the problem (and not just the evidential side effects).

2.. Break the problem up into its constituent parts, come up with alternative solutions to each part, and then accumulate a combined solution(s) to solve these problems.

3.. Choose the optimal solution (or collective solutions) to be implemented.

4.. Determine whether the implemented solution(s) has produced the desired results.

5.. Go back to step 1 and repeat the sequence until the problem & associated problems are either resolved to a satisfactory resolution, or are no longer a pressing concern.

Though, often the best problem solving result is via a collaborative approach of involving other (appropriate) parties in the PLAN – DO – CHECK – ACT resolution; And, the Recognize – Reassess – Revise – Reapply revolution;

A Planner & Organizer

The Project Manager has to be able to coordinate with the project’s stakeholders so as to ensure that the necessary [People] & [Resources] are made available and are kitted-out ready to perform the agreed [Scope] with the agreed [Quality] in the agreed [Time], and to ensure that the agreed [Cost] budget is available so that there is sufficient cash flow to pay for the implementation work to be done.

That is, to orchestrate others to transform “The Plan” into the reality of deliverables.

If the project’s manager is a poor organizer, then no matter how diligently the planning was conducted, the project will be “spinning its wheels going nowhere fast” or come to a grinding halt. This is because, someone [People] or something [Resources] will not be available when required; consequently, other [People] or something [Resources] will have to “hurry up and wait”. Hence, there will be [People] standing around wondering what they should do in the meantime, there will be [Resources] gathering dust & going to waste. And, all the while the project’s [Time] clock keeps ticking away, as the project’s [Cost] expenditure keeps tallying up. Subsequently, the project could operationally turn into a complete debacle, irrespective of what “The Plan” had dictated.

Thus to success, the project’s management has to be able to “compartmentalize” sections of the project into “work packages” that when necessary can be delegated (handed-over) to others to complete within a given [Time], within a given [Cost], using given [People] & Resources.

“And you thought herding pre-schoolers (or soggy cats) was hard. Wait until you’re monitoring & controlling implementers, 3rd parties, and project stakeholders; as this is just as challenging, if not more difficult because you can’t just pick them up and dump them wherever you need them to be.”

A Delegator

To succeed as a planner & organizer; the Project Manager has to be able to (and willing to) designate & allocate activities to other project stakeholders to undertake. This delegation could be downwards to individual Project Implementation Team members, sidewards to other project managers (or equivalent), and when the situation necessitates, then upwards towards the project’s primary stakeholders (i.e. to senior management).

However, delegation does not mean handing over to the delegation-receiver the final responsibility for the activity’s outcome, as this remains with the delegator; i.e. the responsibility remains with the project’s manager.

Be wary of delegating upwards to the project’s primary stakeholders, because doing this too often could start them wondering what is the point you, the Project Manager. Therefore, only delegate upwards those essential decisions related to sensitive risks & issues, and changes to the agreed & approved [Baselines].

By not delegating and keeping all of the work to oneself, the Project Manager is burdening themselves with a potentially excessive workload. A workload which will be greatly increased when senior management decide to (reward you for the great job that you are doing by) assigning you other projects to simultaneously manage.

In addition to reducing the workload on the Project Manager, delegation has another useful benefit; by delegating some of the work to subordinates, the Project Manager is training their potential replacements.

Why delegate, and thereby make myself replaceable?

Well, one way to make yourself replaceable?

Well, one way to make yourself un-promotable is to make yourself irreplaceable in your current role. … And, if no one else can do your job, then you are “a single point of failure”, where there is no contingency for your unavailability for some period of time.

“Also, its highly motivational if correctly executed with empowerment.”

Additionally, not only is the Project Manager limiting their own promotional opportunities but they are also curtailing that of their subordinates who never get the opportunity to really expand their skillsets & responsibilities. … And subsequently, this can have negative effects on the long-term motivation of the Project Implementation Team members.

“So, not only are you curtailing your promotional opportunities, but you are also impacting on your time availability to your family & friends. Oh, and you can forget about getting a sway of time off for that couple months European vacation, … else, when you get back from your holiday then expect bucket-loads of work and even recriminations.”

Hence, every member of the Project Team should be mentoring his or her own replacement, including the implementers and yourself, as the Project Manager.

4.4.2 Being a “Leader” Project Manager

How diminished are the project’s chances of success if the project’s manager cannot focus The Team’s efforts towards the common goal of producing the project deliverables within the agreed [Time] & [Costs] while providing the agreed [Scope] coverage and conforming to the agreed [Quality]? That is, being able to “lead” The Team achieve or exceed those judgements of “Customer Satisfaction” and “Performance Measurement”, [Section 2.8.2].

What Is Leadership?

“Well, one thing for sure … leadership is NOT a popularity contest, nor who is the most charismatic, nor who thinks they are the smartest person in the room (just because of their subject matter expertise), nor who has the most academic degrees framed upon their office wall.”

Leadership is the ability to communicate common vision of the objectives then inspiring others to be driven to achieving those objectives (as effectively & efficiently as possible).

Leadership Styles

The Project Manager needs to realize (and understand) what leadership styles are compatible with their own personality traits; because, the project’s current situation & prevailing circumstances will necessitate that the project’s management apply differing portions of the following leadership styles:

• AUTHORITARIAN – would be beneficial during a “crisis event” where quick steadfast decisions are paramount to success.

• DEMOCRATIC – would be beneficial during the project’s Planning & Executing Phases where the input of different people’s perspectives & opinions could produce better options and more realistic solutions (than could be perceived solely by an individual).

• LAISSEZ-FAIRE – would be beneficial for the day-to-day functioning of The Team, while the Project Manager deals with those external issues confronting the project.

When selecting the appropriate style of leadership to be applied to the current situation & prevailing circumstances, the Project Manager will also need to consider what is more important to the performing organization at that moment in time;

1. Being task oriented – of completing the project’s objectives asap,

2. Being relationship oriented – of maintaining & sustaining working relationships with the project’s team members (and other parties).

These considerations will mean that sometimes the Project Manager will have to “make hard decisions” that put achieving the project’s objectives ahead of the interests, concerns, and the individual outcomes for The Team members.

Which brings us to the next rule of “Adaptive & Proactive” SDLC Project Management

RULE 39: Leadership is not the wielding of power; but rather, orchestrating & influencing others towards achieving defined & tangible objectives.

THEORY … Leadership Styles.

1. Authoritarian / autocratic – is where the leader is central to all decision making; i.e. an “absolute ruler” come dictator.

While this style of leadership does result in quick decision making, it does not necessarily result in the correct or optimal decision; because, this type of leader does not always listen to or accepts the input & opinions from those whose station is subordinate (or they consider as subordinate) to their own hierarchical rank.

Team motivation & participation, as well as their supposed respect for the leader, are often induced via negative reinforcement and threats of punishment.

However, some form of authoritarian leadership style maybe beneficial during the project’s Initiating Phase and especially during the project’s Closing Phase when The Team could be inflicted with “perfection procrastination” (of aspiring to be 110 complete) before moving onto the next activity.

1. Democratic / participative – is where the leader consults with the group before making the decision, or the decision is based on the consensus of the group.

Team motivation & participation is via self-interest to fulfil the common vision and objectives.

The democratic leadership style is most beneficial during the Planning Phase and the Executing Phase when “team buy-in” is essential for the project’s potential success; hence, why it is the basis for agile techniques.

1. Laissez-faire / free rein – is where the leader removes oneself from the decision making process (almost in entirety), instead entrusting the group or specific members of the group to handle certain domains from thereon.

Team motivation & participation is via the empowered self-interest to fulfil the common vision and objectives. Thought, this leadership style can leave The Team members wondering what is the purpose of the Project Manager.

The laissez-faire leadership style is beneficial when the Project Manager is predominately outwards facing so as to deal with the primary stakeholders’ needs & wants – expectations – perceptions – concerns (i.e. external issues); while the senior project team members (such as The Team leader) are inwards facing so as to deal with the technical issues and the day-to-day of continuing to move the project forwards. Whereby, it is the Project Manager’s role to remove those barriers preventing The Team from advancing towards those stated objectives. Thus, why this leadership style is an essential ingredient to agile techniques.

What Makes A Good Leader?

Before listing what does and does not make a good leader, it must be realized that, the current situation & prevailing circumstances are often determining factors as to whether a person is (in hindsight) a good or bad leader.

For example; there has been many a political leader (who according to the opinion polls) were consider by many of their constituents to be incompetent to say the least, yet when war or natural disasters befell the nation / state then they stood-up and proved to be the right person to do the job. Similarly, there has been many a great crisis-leader who has fallen from grace during civil times.

What are the traits of good leaders?

The presence of self-confidence, high self-esteem, and a belief in themselves.

They provide their followers with a feeling of purpose, well-being, safety in numbers, security, and stability.

They are good communicators of their vision, and they are focused on precisely communicating those objectives that they see as achievable in the short to medium term (with some conceivable connection to a long term plan / future).

They are able to persuade others to follow them, and they are able to drive others towards achieving those short to medium term objectives.

They earn the respect & trust of their followers, and they respect & trust their followers to do what is required / requested of them. … Not micromanaging every aspect of The Plan.

They empower their (in the field) subordinate leaders with the authorization and authority to modify & improvise on The Plan as they believe is necessary to adapt to the current situation & prevailing circumstances that are in affect at the point of implementation.

They (themself) as leader adapt to the ever-changing situations & circumstances. And, not locking themself away in their office bunker, as they hope to ride out the consequences of their plan being different to the unfolding reality.

When necessary (for the greater good of all) they are prepared to make those hard decisions, irrespective of the negative consequence to themselves and their followers.

They take personal responsibility for the outcomes of their decisions, whether that be good or bad. … And, if it does go all wrong then a leader does not look for the closest scapegoats on whom to lay the blame; instead, the real leader is more concerned with getting back-on-track and determining how best to resolve the current issues.

What a good leader is NOT:

Narcissistic – arrogant, self-absorbed, egotists, with an unassailable appetite for power.

Toxic –leading their followers (i.e. the Project Team and the performing organization) in a worst state then when they first started to lead the group.

Which brings us to an addendum to “Adaptive & Proactive” SDLC Project Management.

RULE 39A: What makes a leader is not the willingness to charge into adversity; but rather, the sense to know what & when not to charge.

THEORY … Management Styles [Ref: McGregor]

The Project Manager needs to determine what style of manager they are likely to be.

• THEORY X MANAGER – the “no you can’t” manager will intrinsically need to micromanage every little thing that the Project Team members do.

This style of manager will often be driven by some innate mistrust of The Team members that they will not do their jobs, because they are lazy unmotivated slackers who will (whenever possible) go out of their way to avoid work and they will cheat & lie about the work that they have & have not done. And/or, this Theory X manager believes that The Team members don’t have the sufficient skills to advance the project forwards without that manager’s continual guidance & instructions.

Hence, the Theory X manager will be highly restrictive with the delegation of work and the allocation of responsibility to the Project Team members, even going as far as to silo team members in discretely demarcated job roles. This will all be based on the manager’s belief that the only way to get these “workers” to do their jobs (other than by the pay-cheque) is by the use of rigidly defined hierarchical work structures and draconian work processes & procedures (which includes baseline quantifiable statistics for performance goals and the punishments for non-achievement).

In a performing organization where there is a desire to be people oriented instead of purely procedural (e.g. agile instead of production line), the Theory X manager can have a devastating effect on the Project Team’s morale. This is because, the Theory X manager often believes that whenever something goes wrong, it is the workers’ fault “because they must have not abided by the details of The Plan and/or they did not follow the stipulated processes & procedures”; instead of considering the possibility that the failure was due to mitigating considerations of the current situation & prevailing circumstances. … “Or due to the manager’s own failings.”

For a performing organization that is using an agile implementation methodology then the Theory X manager is completely at odds with the underlining principles of agile, that it is The Team and not the manager that drives the Executing Phase of the project.

The Theory X manager is more suited for the traditional waterfall (and some iterative) implementation projects where micromanagement is the expectation.

THEORY Y MANAGER – the “yes we can” manager will trust the Project Team members to do their jobs, and feels confident that each member will not let The Team down (and for that matter, let the project’s management down).

This style of manager will be driven by the belief that The Team members will be self-motivated to do their job as best that they can, given the current situation & prevailing circumstances, and based on the training & experience that they have.

Hence, the Theory Y manager will be prepared to delegate areas of work and allocate responsibility to The Team members, even going as far as encouraging cross-functional team arrangements. This will be based on the manager’s belief that to motivate The Team members (to perform at their best) then they have to be presented with challenging work, problems to solve, opportunities for growth & advancement, and diversity in their roles & responsibilities.

In a people orientated performing organization, the Theory Y manager will have a beneficial effect on the Project Team’s morale. Hence, the Theory Y manager is what is required for a project being implemented using an “adaptive” agile methodology.

However, in a procedural (waterfall) performing organization, the Theory Y manager could be driven mad by the bureaucracy & inflexibility. … And, downright frustrated by the inability of the organization’s senior management to (dynamically) adapt to the changing situation & prevailing circumstances that now confront the project.

Though, a project manager is not all Theory X: Theory Y, or a sliding scale with the two Theories at opposite ends; rather, a spectrum of both styles amalgamated into one.

4.4.3. Your Personal PM Credo

When you get up in the morning and look at yourself in the mirror, what defines the person that you see reflected back at you?

At some point in your project management career (especially when the economy is bad and your employer is not doing so well), you could be requested to do things that are at odds with your sense of business ethics and your personal morals.

So, how will you handle such requests; yet, still be able to look at yourself in the mirror?

P.E.R.I.O.D.

Patience – Effort – Respect – Integrity – hOnesty – Dignity.

• PATIENCE – to given reasonable & sufficient time for individuals & groups (and yourself) to get things done to an acceptable level of quality and scope coverage. … And, not rush things through, so that, all that can realistically be delivered is a makeshift resolution that is riddled with unsatisfactory compromises.

• EFFORT – to give (and expect) reasonable & sufficient effort to be put in by individuals & groups (and yourself) to get things done to an acceptable level of quality and scope coverage. … And, not to over-work / under-work people, so that, all that can realistically be delivered is burnt out individuals and/or a half-baked resolution that is riddled with unsatisfactory compromises.

• RESPECT – to give due regards to individuals & groups (and your own) efforts, capabilities, experiences, and responsibilities so as to empower them to do what they deem necessary to be done to achieve the stated objectives; without being second guessed, undermined, and/or overridden by (micro) management from above.

• INTEGRITY – to be truthful & accurate in what data / information is presented.

• HONESTY – to be truthful & sincere in what is said.

• DIGNITY – to be truthful & humble in what is done and how it is accomplished.

EXAMPLE CASE … Business ethics versus your personal morals.

Consider the following real-world scenarios.

You are (verbally) requested by senior management, “to just”, invoice the customer for a portion of the project work that is yet to be done. Though, your boss has reassured you that it will be done first thing next month. But, it needs to be invoiced now, so as to improve the organization’s financial results for this quarter’s / End Of Financial Year’s reporting.

You could raise your concerns, hesitate to do what is requested, or you could humbly decline to do this request. However, would your “high morals” stance be marking you as “not a team player”, and hence could you possibly be limiting your future career prospects at that organization (under that management reign)? … And, what would happen if you decided to escalate this issue, to those bosses above them?

…

There are two unrelated but simultaneous projects for the same customer. Both of these projects have been “sold” to the customer as being 1000 hours of effort each. However, during the implementation, one project is a lot easier than expected and only required 750 hours of effort, whereas the other project was harder than expected and required 1250 hours to complete. Your senior management tell you, as the Project Manager, “to just”, shift hours in the timesheet system from the over-hours project to the under-hours project, and then invoice the customer as though each project was in factuality a 1000 hour job. … As there is “no overall harm done”, as the customer got what was promised, and the performing organization “broke even” on both projects.

…

There is a fixed price project for the customer, and at the same time, that customer also has an ongoing contract with the performing organization to provide a certain number of maintenance & support hours per year for their suite of products. However, during the project’s implementation, it goes way over the hours of effort and will be a loss make for the performing organization. Your senior management tell you, as the Project Manager, “to just”, shift hours in the timesheet system from the over-hours project to the maintenance contract’s job code. … Given that, “the customer is not using up all of those maintenance contract’s job code. … Given that, “the customer is not using up all of those maintenance hours, and the project’s product output would just use up those maintenance hours when it’s released, so might as well just use those maintenance hours now during the product’s development”.

…

So, HOW FAR IS YOUR SENSE OF REAL-WORLD BUSINESS ETHICS PREPARED TO BEND?

Before you decide on what is right & wrong, reconsider those previous examples and the following examples, and set these during a major financial crisis for your employer.

…

There are two unrelated but simultaneous projects for two unrelated customers. One project is going really well and is not consuming all of the planned hours of effort, but the other project has real problems and is burning through its hours of effort. Your senior management tells you, as the Project Manager, “to just”, shift hours in the timesheet system from the over-hours project to the under-hours project, and then invoice each of these independent customers as per the timesheet factualities.

There are two unrelated but simultaneous projects for two unrelated customers, but there is a common body of work to be developed. Your senior management tells you, as the Project Manager, “to just”, book both customers for the full amount of the common work. In essence, invoice double dipping.

…

So, HOW BENDABLE IS YOUR ETHICS, “just to” retain your job during such as economic crisis? … “Oh, and those customers are your national government.”

“IT IS THROUGH ONE”S OWN BATTLES, THAT ONE DISCOVERS WHAT DOES AND DOES NOT WORK FOR THEM_ ___ GIVEN THE SITUATIONS AND THOSE PREVAILING CIRCUMSTANCES.”

That sounds like a Sun Tzu “Art of War” style of retrospectively stating the in hindsight obvious, having experienced similar situations & circumstances.

NOTE: Each of the following example case “field test” scenario projects focuses on different real-world aspects of project management (both the good & the bad) that you are likely to encounter at some point in your PM career. … And, sometimes, these situations will be experienced again & again, like déjà vu; yet, as one project finishes and the next project begins, the same underlying “high impact” mistakes will be made (and these repeated mistakes will not necessarily be made solely by the Project Manager, but by those even higher up the chain-of-command).

Therefore, the following chapters detail the occurrence of these situations, and how to cope with these various situations; subsequently, some sections of the following chapters may feel a bit like a scientific formulated text on the processes & procedures to be utilized as mitigation & correction techniques.