Literal Thinking

Real stories of workplace follies

Archive for February, 2009

Blogging for money, vanity, and personal development

Posted by A Friend on 28 February 2009

Blogging Badge A few weeks ago, we facetiously left a comment over at the Creative Energy Officer blog that reasons for blogging can pretty much be narrowed down to two: money or vanity (or both). It was meant as a joke of course, but when we were forced to think about it more when the blog author followed up on us, we realized that we were probably closer to the mark than we initially thought.

A lot of people make money off the internet these days and a whole lot more have attempted to. We don’t have a statistical backup, but we suspect a good number of those making money and attempting to make money off the web do so through blogging. The internet has experts and wannabe experts who can tell you all the essentials about this. The only point we want to stress is that blogging for money is not only restricted to getting ad revenues from your blogs. A lot of bloggers use their blogs as extensions of their brands or platforms to demonstrate subject matter expertise. Lorelle on WordPress is a good example of an ad-free blog that most likely generates a lot of business for its author.

We also claimed in our comment that those who do not blog for money do so for vanity. Blogging is a cheap and easy way of putting your voice out there for the world to listen to, and we are in no doubt that bloggers at least get some sense of satisfaction when they know that people visit their blogs. We know we do, and though our blog is only a couple of months old, we have already caught ourselves a few times unhealthily obsessing about visitor statistics.

Regardless of the reason, we suggested that readership is essential to the survival of a blog. A blogger can only talk to him or her self for so long and if readers don’t follow, the blogger will eventually lose interest and the blog will die a natural death.

We admitted in our comment that we probably fall in the vain category. The blog platform that we chose does not allow advertisements, so we’re definitely not here for ad revenue. The nature of our blog requires us to post anonymously, so we can’t be here to promote ourselves or our services, either. Finally, there’s the vain act of addressing ourselves in the plural form.

But a really important reason why we started this blog is for our own personal development. While the slogan we chose for the blog, “Real stories of workplace follies”, may sound a bit negative, our focus is not so much about the mistakes made, but the lessons that can be learned from these. We firmly believe that the best life or business lessons are learned from negative experiences. Of course, one does not go around aiming to fail. But as one of our all-time favorite poems states, “Success is failure turned inside out, the silver tint of the clouds of doubt”: there are a lot of opportunities we can derive from failure, we just need to know how to.

One way of truly learning from a negative experience is to try to objectify it. This is essentially what we are attempting to do in the case studies that we present here. We try to step back and strip the emotion from the experience, and attempt to present the cases with just the bare essentials. We understand that perfect objectivity can never be accomplished, especially when we are personally and intimately involved in the experience, but we try to get as close to it as we possibly can.

The blog is fairly young, and we have so far only been focusing on presenting the cases. At the end of each case is an implied question of what went wrong and how things could have been done better. As the blog grows (and we hope it continues to grow), we are aiming to also write posts about the learning derived from the cases. After all, the whole point is to learn from the experience.

Advertisements

Posted in WOTM | Tagged: , | 4 Comments »

The perennial time and scope dilemma, part 2

Posted by A Friend on 24 February 2009

In a Pickle In our last post, we began presenting a case that illustrated the time and scope tension project managers often face. This tension can be especially heightened when signoff points for scope deliverables and phase completion are crammed together in one small time block, usually coinciding with the end of a particular project phase. This is the second part of the case, where we look at some of the major signoff decisions made, and the consequences of such and earlier decisions, at the latter stages of the project.

User Acceptance Testing

User acceptance testing (UAT) started with a big conundrum: who should do the testing? One train of thought was it should be the client’s key users, as they were the ones who knew the existing system and process requirements and should be doing the tests to ensure that the to-be solution met all of these requirements. Another view was it should be the vendor’s key outsourcing users, as they were going to be the ones using the system on a day to day basis, post-implementation. In the end, members of the vendor’s implementation team did the testing, the very people responsible for building the solution. It was a glorified unit test, and a farcical user acceptance test activity.

This was an unexpected requirement for the implementation team, so they were naturally not prepared and had not planned for it. UAT test scripts, which should have been completed and signed off in an earlier phase of the project were haphazardly done, often recycled from previous projects that had little relevance to the current one.

The project managers then decided that because of time and resource constraints, UAT was only going to be executed against core system functionality and maintained at a very high level; and all custom development testing was postponed to the next project phase. But even with this minimal requirement, it quickly became apparent that proper testing was going to be an arduous process, mainly because of the low quality of data loaded during integration testing and the still incomplete enterprise solution. So despite the significantly reduced scope, UAT could not be completed on time.

To ensure that the project remained on track, both client and vendor project managers decided to start parallel testing while UAT was still going on. UAT and parallel testing thus ended up running in parallel.

Parallel Testing

To make sure that the to-be solution met the client’s system and process requirements, the project simulated a parallel run over two months’ worth of transaction data. Parallel testing started at a later stage of the project, so the data migration team had more time to ensure that the quality of data loaded for parallel testing was of a much higher quality. But the good news ended there.

Virtually every process in parallel testing ended in error and data between the legacy and the new system just could not be reconciled. Various factors contributed to these errors: poor data quality coming from the source systems, incomplete configuration of the enterprise solution, and highlighted missing functionality in the to-be system.

The premature and forced deliverable signoffs done during the initial stages of the project was finally taking a heavy toll and putting tremendous pressure on the project team. Despite this, a very tight deadline for parallel testing completion was still followed, and strong arm tactics continued to be used by the project managers to ensure signoff. The parallel testing team was forced to manipulate data and introduce quick system configuration solutions just so parallel testing could be green-lighted on time.

The problems with the core solution encountered during parallel testing and the required efforts to address these also meant that signoffs of some solution components and functionality, and of various custom developments, were yet again postponed to the next phase of the project.

End to End Testing

End to end testing was identified as a key phase to be completed during project initiation to see whether the enterprise solution and the outsourcing organization could cope with the client’s end to end business process and service delivery requirements. Incredibly, some solution components, various custom developments, and UAT and parallel testing, were not yet completed before end to end testing was to start.

The end to end testing process itself was chaotic. There were yet again no test scripts written; and while the project had members who were experts in their individual work components, it had no identified business process experts. The project team did not have a clear understanding of an end to end business process to test, and no expert to look to for guidance.

Faced with time constraints and the lack of expert advise, both client and vendor project managers, not for the first time, decided to only take a helicopter view of the entire business process chain for end to end testing. And once more, even with this reduced scope, the to-be solution was found wanting.

Last-minute change requests to address process gaps were quickly approved, half-thought of solutions were developed and signed off, and an alarming level of testing variance against benchmarks was accepted and approved. All this was done for the singular purpose of meeting the project’s time requirements.

Go Live Cutover

The project reached go-live cutover without a cutover plan, with both client and vendor project managers still swamped with issues to close out: some custom developments were still not properly tested, let alone signed off; acceptance of testing variances were still being debated; and more change requests were being considered.

The big volume of issues still outstanding forced both client and vendor to bring in two additional project managers, with the sole brief of working together to take the project to go-live cutover. These two “cutover managers” had no experience in the project yet were given free reign to map out the go-live cutover plan.

A mad rush of signoffs and completions occurred in the last two weeks before going live. Changes to system configuration, with minimal testing, were introduced very late in the project because of even later solution gap identification. Critical custom developments with barely there testing were finally signed off, with some developments just getting completed during the last weekend before go live.

Data migration took two weeks to complete, with the data migration team losing count of the delta loads done. No one could swear on the integrity of data loaded into the new production system, and everyone crossed their fingers when go live cutover was signed off – on time.

– o –

We are deliberately stopping the case discussion at just before go live to let you, the reader, imagine how go live – and the immediate post go live – activities went. What is most amazing is this project was actually delivered on time and on budget; and with some creativity, it can even be reported to have been on scope.

Posted in Case Studies, Project Management | Tagged: , | 2 Comments »

The perennial time and scope dilemma, part 1

Posted by A Friend on 19 February 2009

Dilemma In our last post, we introduced a fairly familiar project scenario where signoff points for scope and time overlap. This typically happens when deliverable (scope) signoffs are crammed into one time block, often also coinciding with the end of a particular phase (time) of a project. In some projects that we have seen and been involved in, this simplified approach had led to project managers choosing to either compromise on scope or on time (sometimes both), just to make the signoff point. We call this the perennial time and scope dilemma.

To illustrate this time and scope tension, we will walk you through some of the key sign-off decisions made in each major phase of a global IT outsourcing project by a large consumer goods manufacturer (hereafter we shall refer to as the client). The project was undertaken with support from a consulting partner (hereafter referred to as the vendor) that was also going to be the outsourcing organization after project completion. This is the first of a two-part series.

Business Blueprint

The business blueprint document, arguably the single most important document in any IT transformation project, was signed off unconditionally with major sections of it indicated as “to be completed”. The vendor used strong arm tactics to force the client to sign off, arguing that the blueprint completion delay was singularly due to the client not being able to provide the required resources for on-time delivery. For the client, it was a matter of signing off on an incomplete blueprint, or paying a hefty delay cost.

The client cascaded the strong arm tactic down to its internal subject matter experts (SMEs). The SMEs were forced to sign off on the data migration design and plan without being given the opportunity to seriously assess project implications to both their retiring and retained systems and processes; or scrutinize two 150-page documents and four complex workbooks, which were to be used as primary tools for transferring data.

All custom development functional specifications were conditionally signed off, contingent on missing blueprint information being provided in the next phase of the project and proper assessment of proposed technical solutions. It was correct to conditionally sign off these deliverables, but their dependence on a completed blueprint document, when it was already unconditionally signed off, was a big risk.

The sign off requirement for a go live checklist was postponed as it was deemed unnecessary at such an early phase of the project. The project would eventually go live without a formal checklist being signed off.

Solution Build

It quickly became clear to both client and vendor that the business blueprint documentation did not contain adequate information to allow the vendor to build a complete enterprise solution. The vendor tried to push the client to raise change requests; while the client pushed back, arguing that while the business blueprint documentation may not have been completed, the enterprise solution requirements had always been clear.

Client and vendor met halfway, but a lot of effort was wasted on just scope renegotiations. The checkpoint was reached, and the enterprise solution was not yet completely built. To ensure the project continues on schedule, both client and vendor project managers agreed to conditionally sign off on the enterprise solution, with the proviso that incomplete components will be progressively delivered in the next phase.

The conditional signoff of the enterprise solution had a trickle down effect on the rest of the deliverables. For example, the data migration processes and most of the custom development requirements were reliant on the enterprise solution being completed, so these were also conditionally signed off.

Part of the conditional signoff of some custom development deliverables was also due to the lack of time to complete the developments. The original project schedule was made based on a number of assumptions, one of which was the number of custom development requirements. These requirements were significantly underestimated, but the broader scope did not deter both client and vendor project managers from sticking with an ambitious delivery schedule.

Finally, some other requirements like super user training and cutover planning just could not be delivered with a half baked enterprise solution, so signoff for these were postponed to the next phase. Not surprisingly, these were not looked at again until late in the project.

Integration Testing

Integration testing is all about making sure that the to-be-implemented enterprise solution can replace retiring system functionality, including integration with mission critical retained systems and processes. With an incomplete enterprise solution, integration testing for this project was a shambles. In fact, proper integration testing processes were totally ignored, and activities during this phase were more to ensure that systems and processes were ready for user acceptance and parallel testing (the next phase).

Full end-to-end data migration testing was a mess. The client did not have enough time to analyze their source system requirements; while the vendor was still in the middle of building the solutions during data migration testing, so the target system requirements were also not yet properly defined. The whole data migration team struggled to get data loaded properly, and virtually every step of data migration had errors. In the end, the goal changed from end-to-end data migration testing to just making sure that data is loaded into the user acceptance and parallel test systems. There was no proper data validation process, and strong arm tactics were used to force the data migration SMEs to sign off on data migration testing.

A lot of the custom developments, most especially interfaces to mission critical systems, could also not be tested properly. This was due to the incomplete configuration of the enterprise solution, the lack of meaningful data to test against, and the still ongoing development activities. Without much headway and with the project still chasing its time requirements, a lot more of the custom developments were conditionally signed off, contingent on these passing user acceptance and parallel testing.

Our case discussion will continue in our next post, where we will present some of the signoff disasters in user acceptance testing, parallel testing, end to end testing, and go live cutover; as tension between delivering on time and on scope mounted.

Posted in Case Studies, Project Management | Tagged: , | 1 Comment »

Of project signoff points

Posted by A Friend on 14 February 2009

Project Signoff Board Any size or type of project will have identified deliverables that need to be completed and signed off at key points during a project’s lifecycle. The signoff signifies completeness, or at least business acceptance of the deliverable.

Most large scale projects will have a long list of deliverables that need to be completed for the duration of the project. Some of these need to be completed very early in the project (e.g. a project charter), some not until the project is completed (e.g. a post project review). Often, the number of phases a project will have is dictated by the number of deliverables required, and when these are required to be completed.

While some complex and well-run projects may identify specific signoff points or dates for each and every defined deliverable, most projects we encounter and have been a part of adopt a more general approach of having the signoff points coincide with the end of a particular phase of the project. The great advantage of this approach is it simplifies the monitoring requirement for deliverable signoffs from a project management perspective. Its one significant disadvantage is it can lead the project managers to slacken their grip on deliverable scopes and timelines.

The end of individual phases in a project also typically serves as checkpoints. Checkpoints are often where formal reassessments of projects take place, where a check is done to see whether the project still serves the business case for which it was launched; this check determines whether a project proceeds to the next phase or is terminated or re-scoped. Checkpoints are also often where partial payments are made to third parties that may be involved in project delivery; that is, a consulting organization helping in the delivery of a project gets partial payment for its full consulting fee during the completion of every phase of the project they are helping with.

Coinciding delivery signoffs with phase signoffs and/or checkpoints helps simplify the monitoring tasks of project managers. But it also puts a significant burden on them to juggle two often conflicting items in a project: the pressure to deliver on time, and the pressure to deliver on scope. Quite often, it is the pressure to deliver on time that takes precedence. And this inevitably means striking a compromise around scope delivery.

Some of the tactics project managers utilize to “force” deliverable signoffs just so they can meet their time requirements include:

    Conditional signoffs. This is when deliverables are signed off on specific conditions that will need to be met in the succeeding phases of the project. There are some deliverables that will naturally require conditional signoffs. In an IT project environment, functional specifications for custom developments are often written early on in a project’s blueprint phase when only key functional personnel are involved. During the build phase, when developers start joining the project, it may be found that some of the functional specifications are “technically impossible” to implement. To ensure that there is scope for functional specification adjustments, these are only conditionally signed off at the end of blueprint.

    Acceptable variance signoffs. This is when a deliverable is signed off even when it has not completely satisfied the original requirement but is delivered within an acceptable variance of the original scope. Going back to our conditional signoff example for custom development requirements, it may be found during the build phase of the project that some functional requirements originally identified during blueprint cannot be accommodated. An acceptable variance signoff for a custom development can be made if it addresses the key business requirements, and even when some of the nice to have bells and whistles are not delivered.

    Postponed signoffs. This is when the signoff of a particular deliverable is postponed or moved to the next project phase or checkpoint. Unless a deliverable is mistakenly identified as a requirement earlier than it should be – which itself is unacceptable – we strongly believe that there is no reason for signoff postponements. Deliverables are often required at a particular point because serious consequences can happen if their deadlines are not met. For example, the statement of work is a requirement at project initiation; a fourth draft of the statement of work should not be floating around for signoff during a project’s build phase.

    Arm twisting. This tactic is not as sinister as it looks, but it is essentially as it is written. The signoff parties for most deliverables are often subject matter and business process experts (SMEs/BPEXs), not the project managers. Project managers use the arm twisting tactic by imposing unreasonable deadlines and scrutiny on the SMEs and BPEXs that they often feel like they are left with no choice but to signoff, even when signoff processes have not been duly followed. Of the signoff tactics used, this is the riskiest, as this can mean that deliverables are signed off even when the business requirements are not met.

This post was originally meant to only be a one or two paragraph introduction to a project management case where an overemphasis on “on time completion” put significant risks to the project as it struggled to meet its scope requirements. It developed into a post of its own as we feel it important to establish some background around the tension between delivering on time and on scope. We will present the case in our next post.

Posted in Project Management | Tagged: , | 6 Comments »

The case of the red-faced autocratic leader

Posted by A Friend on 9 February 2009

Headless Dictator This is the third of a three-part series where we present short cases of spur of the moment statements made that led to unfavorable results taken from our own practice. The underlying theme of the series is some thoughts are just not meant to be spoken, even if these were true.

Jordan joined a global consultancy as the new managing director in one of the company’s developing country offices. Jordan was in the military for a few years before finding success as a business executive, so his management and leadership style has a strong military influence. He is very authoritative, straight to the point, and results driven. He is also brash and abrupt; and in a behavioral test done as part of one of the company’s team building activities, he scored zero for empathy.

Jordan very quickly established himself as a strong organizational leader who sets the pace and dictates directions, and he gave his employees very little scope to exercise their own creativity and initiative. This is a practice more common in some military organizations; and this management approach is also typical of many developing country companies, especially in Asia.

But while it’s true that Jordan was managing a developing country office, most of his employees were high achieving professionals, with a number of them experienced at C-level advisory consulting. His controlling behavior made some of his junior consultants feel inadequate, but the more senior ones who rightly believed they were much too experienced to just follow his directives just felt resentful.

Within six months of taking office, Jordan started seeing some of his consultants leave. In one case, Christina, a mid-level consultant who had been very vocal about her disgruntlement with new management, filed her resignation. In the exit interview, Jordan asked Christina what her plans for the future were. Christina coyly responded that she might try applying for consulting positions overseas.

Jordan haughtily responded: “To be honest, I don’t think any of the consultants in this practice are qualified to work overseas.” This shocked Christina, so she honestly replied: “Actually Jordan, I already have an offer to work in our London office.” After which she stormed off, leaving the red faced Jordan pondering how such could have happened without him getting an inkling of it.

Needless to say, the story of the exit interview spread like wildfire to the rest of the organization. And Christina was not the last person to leave, nor was she the last to find an overseas assignment.

Jordan’s management style is in itself an interesting case study on autocratic leadership (Mindtools has a good overview of common leadership styles). We suspect that it was especially hard for him to not take a parting shot at Christina, just to further stamp his authority. But just as autocratic leadership has generally gone out of favor, Jordan’s cynical attempt to disparage for no clear reason spectacularly backfired.

– o –

Blog Carnival. The February Leadership Development Carnival is on at Dan McCarthy’s Great Leadership blog, and it’s worth a visit or three. Over 30 articles from some of the best blogs on leadership and management are featured, including one we wrote on personal responsibility. This is our first time to send a submission to a blog carnival, so we are pleased to have been included.

Posted in Case Studies, Communication, Leadership & Management | Tagged: , | 2 Comments »

The case of the pompous graduate

Posted by A Friend on 4 February 2009

Job Interview This is the second of a three-part series where we present short cases of spur of the moment statements made that led to unfavorable results taken from our own practice. The underlying theme of the series is some thoughts are just not meant to be spoken, even if these were true.

Erin is a graduate of one of the top universities in the country. Her school consistently makes it to the top of major placement surveys for graduates, and its graduates are often the first to be snared and given the highest starting salaries by the biggest companies in the region.

So Erin was very optimistic about her employment chances. She should be, considering that she already had three very positive employment interviews two months before she was to even officially graduate. But Erin did not want to be rushed into making a decision, and she told all three prospective employers that.

Erin received a few more interview offers in the succeeding months. She actually felt that she was offered more than she could reasonably handle, so she even found it necessary to politely turn down a few of the invitations. Of those that she attended, the result was largely positive. She had a couple of ordinary ones, but Erin thought that this was just part of the law of averages.

It was not until a month after graduation that Erin took job hunting more seriously. She started going for second interviews and began the arduous – it is, for in-demand graduates like her – task of sifting through some of her prospective employers. In the end, she chose three companies that she would be happy to work with.

One of these companies is a global IT services firm that is known for its popular two-year training program for its graduate recruits. The program starts with a three-month intensive course in its state-of-the art overseas training center. This is then followed by rotations in at least three different departments that graduates choose, based on their individual interests and competencies.

The prospect of attending this two year intensive course, plus the opportunity to have a “free” three-month overseas holiday, was greatly appealing to Erin. She only had two problems: (1) the company, of the three that she short-listed, offered the lowest starting salary; and (2) starting salaries are standardized, and Erin felt that she should at least receive some premium because she is a graduate of the best school.

In her final interview, Erin’s prospective manager told her that the company generally recruits 20 graduate trainees every year. The trainees come from at least five different schools, with only around ten per cent of these coming from Erin’s school. Erin found this piece of information a great negotiating platform for a better salary.

Erin told her prospective manager: “I understand that you standardize the salary package you offer your graduate recruits, but I strongly feel that you should give me a premium. Compared to the majority of your prospective recruits, I’ve had better training and preparation for work after graduation, considering that I come from a more reputable school.”

The look of disappointment on her prospective manager’s face could not be masked after Erin said this. The prospective manager said: “I would have considered any other reason you used to negotiate for a higher salary, but I cannot accept this. And I cannot accept someone who already feels she is superior to her prospective peers even before she gets to meet them, so I will also have to regretfully withdraw our employment offer.”

Once the shock of the message died down, Erin’s interviewer helpfully said that he is sure Erin would find good employment elsewhere. He said that his withdrawal of the offer was more to hammer the point about humility and learning how to communicate properly. It is one thing to feel confident about one’s abilities, but it is another thing to pompously verbally communicate such confidence.

Posted in Career Management, Case Studies, Communication | Tagged: | 5 Comments »

Friendly communications, unfriendly consequences

Posted by A Friend on 1 February 2009

Careless Whispers Some of the most common workplace follies we see occur when people too quickly speak their minds out only to realize a second too late that they would have been better off keeping their thoughts to themselves.

In this and our next two posts, we will present some short cases from our own practice where spur of the moment statements made led to unfavorable results. The underlying theme of this series is some thoughts are just not meant to be spoken, even if these were true.

Eric is a young consulting professional working for a big four type organization. Eric was with a small boutique consultancy prior to joining this company, and while he is “in the big league” now, he made it a point to maintain friendly ties with some of his former colleagues.

Eric’s current and former companies are directly competing in a high growth segment of the local market. His previous company was one of the pioneering niche players, his current one a global behemoth that sees and wants to take advantage of local growth opportunities.

In one high profile project prospect, Eric’s current and former companies decided to submit a joint bid. The former company has the established local reputation, the current company has the financial clout and global name – it was going to be the perfect collaboration.

On paper, that is. In reality, Eric’s previous company sees the joint bid as its only opportunity to be involved in projects of such a large scale, considering that it does not have the financial muscle to be a sole bidder. On the other hand, Eric’s current company looks at the joint bid merely as a convenient entry point into the local market, and it intends to eventually ease the small partner out of the project.

Eric thought that he could quickly make a name for himself in his current company by being the unofficial liaison between the two new partners. He communicated directly with some of his previous colleagues about the new project prospect, mainly on a social level, and all in an unofficial capacity.

In one such social communication, Eric matter-of-factly mentioned his company’s plan of slowly easing his previous company out of the joint bid. It was just a purely social conversation, and he did not think much of it. Until the next day, when he was called in by his managing director, advised of a formal reprimand about company confidentiality, given clear instructions to stop communicating with his previous colleagues regarding company matters, and officially rolled off the prospective project team.

When this case happened, Eric was looked upon as a young consultant with a very promising future. However, there are things that one learns only from experience. As a budding consultant, Eric was keen to build rapport and relationships. This unfortunate experience will tell him that such an exercise does not require total honesty in all situations.

Posted in Case Studies, Communication | Tagged: , | 2 Comments »