How to Hold a Customer Hostage Part II

Purely fictitious for the fun of exploration, this submission explores what it looks like when vendors of a product and/or service effectively hold a customer in a form of stasis - never really delivering, never really finishing, and never really providing enough understanding for the customer to be happy, sad or equipped to decide to stay or leave - just unfinished, bleeding money. Because of the size, this post is broken into multiple parts.

Part I
Part III
Part IV
Final Report

Continued from Part I:

So, now that the contract is signed, and everyone with influence agrees this project should be executed as currently planned, it moves along to the prototyping and design phases of the project.

On June 15, 2000 - Even though the previous report suggests the next step is to be prototyping, many voiced concerns it would not render enough progress to justify cost and timeline. Resultantly, two primary concurrent activity streams are then kicked off in one public, mass "Project Launch" meeting. Secondary streams are discussed, though are less prominent.

Stream 1: Component architecture vendors are contacted; try before you buy deals are struck where possible and purchase orders are cut for those things which couldn't be negotiated; base hardware is ordered where existing hardware could not be freed up to test hypothesis; and team membership is modified for the next phase adding experts and load-bearing people where necessary for development integration, scripting and testing activities. This effort is estimated to take 30d to acquire all ordered/negotiated hardware and software and get it integrated and running in a non-optimized fashion + 15d overage in the event some vendors are less responsive than expected, or integrations simply require more work than anticipated. Between DBAs, SysAdmins, Architects, Developers, Project Leaders and Staffers, there are twelve people on this team. As the contract was re-negotiated, the mixed hourly rate is now averaged at $95/hr spanning FTEs and Consultants.

Stream 2: Designing a UI according to current Human Factors (HF) standards will require significant field study and a few experienced HF resources from the consulting company currently hired to lead the effort. The United States is divided up into four primary regions, four teams of three people are created (1 Senior consultant, one junior consultant, and one host company regional support staffer) to traverse four different offices within each region which seem to represent the majority of daily/monthly revenue and risk. This effort is estimated to take 30d +15d overage in the event of travel problems and resource (superuser) unavailability.

Secondary streams were briefly discussed including statusing, milestone management, planned versus actual financials, testing, and marketing plans. Five people considered to be experts in software projects were assigned to think and plan for all of these subjects (except marketing in which they are expected to simply keep marketing expectations in mind) and answer/take direction from the Project Manager.

On July 15, 2000 Status meeting - The large group came back together to discuss progress, successes and challenges ahead of the teams.

Stream 1 - Prototyping - Two software components were acquired, implemented and independently tested suggesting potential positive future results. Three software components proved questionable, with one in particular being quite contrary to get installed, configured and used in the current environment without unplanned consulting hours from the vendor for hand-holding purposes. Ordered hardware arrived as planned, but was delayed on install due to the Corporate Security group having issues with the h/w and s/w OS versions not being on their current 'approved' list - which then delayed the SysAdmin teams from doing installations until given the stamp of approval (with conditional time-based approval) from the security group. Seven days elapsed from point of h/w receipt to actually installation and accessibility. This team reported progress and suggested it would continue working to achieve stated goals prior to the next meeting. Someone mentioned the planned overage allowed 15d, but the conversations suggested it may go longer. The Project Manager spoke up and mentioned that getting the prototype right the first time was the goal; the team would stick to the planned timeline; but there would be conditional analysis along the way determining if in order to get it right the first time, more time was necessary.

Stream 2 - Human Factor Analysis for UI Design - All planned traveling occurred as communicated including audio-taped interviews, and hours of videotaped end-users working in their cubes during typical business days. Distillation of data is in progress and will be published in time for the next project meeting in 30days. The HF group plans to publish all material in time for one or two rounds of feedback and document editing with a formal baseline published and announced in the next large meeting.

Stream 3 - Development Design Begins - It is announced that the development team is being formed from existing host company staffers, as well as, augmented by multiple consulting resources to mitigate the risk of upsetting production support and customer satisfaction within the host company - i.e., more consultants means less staffers are interrupted in their production work. The role of the development group, co-led by one host company staffer and a senior consulting developer, will be defined, coordinated, led and managed by this two-person leadership team. As currently planned based upon all existing knowledge and data, design documents will be drawn up first using the functional requirements and prototype decisions. UI considerations will occur later in the project. No timeline is set yet, but an update is expected in the next major meeting regarding timeline and deliverables. This team is comprised of six people right now.

Meanwhile, the Project Manager met with the Project Sponsor on a weekly basis to review risks, issues and needed decisions in order to make things go faster and more productive. The Project Manager assured the Project Sponsor that in order to make sure costs are controlled appropriately, it is quite reasonable for the prototype and UI groups to extend their timelines a little bit now so that we are assured less rework later. The report is distilled down to a "red, yellow and green light" approach where "green" suggests all is well, "yellow" suggests there is a risk, but is being managed, and "red" suggests there is a problem, it is an issue, and needs to be addressed immediately. Planned versus Actual timelines and expenditures are discussed, as well as, how well the teams are working together.

On August 15, 2000 - At the next big group meeting, the general status was simply one of "you are here" more than anything else. Balloons, music and small gift bags were handed out as usual in order to continue theme-based excitement at the meetings. The meetings at this point seem to be somewhat ceremonial given there are now multiple sub-project managers, team leads, and remote stakeholders flying in to speak at the meetings.

Stream 1 - Prototyping - A baseline Prototype Results document is presented to the group showing the fundamental components of the system which is now considered 'ratified' by members of the prototype team and ready for inclusion into the design process. Document audience: Architects, Designers and Senior Developers.

Not all test results desired were available at the time of the meeting in order to answer questions about interoperability and performance test results; but said results were committed to be distributed after they were gleaned later in the project. Cost of acquisition is mentioned as a prerequisite used for evaluation. No mention of cost of ownership or return on investment come up.

During the meeting, people uninvolved in the prototype effort expressed concerns that some of the components and technologies needed to perform said work were new to the organization and would seemingly require people to be re-tooled. The Project Manager stepped up to start the conversation by mentioning that it is a known risk, but an appropriately calculated step in evolving the company pursuant to stated corporate goals. It will require some new skill-sets and the company is planning to help staff retool if and when necessary thereafter. Well enough.

Then someone from the security group opened up and mentioned that some of the components in the stack were not explored or approved by the corporate security group and would require independent validation. Again the Project Manager stepped up and observed that he understood not all things were yet corporate ratified, but he was under the impression from the Project Sponsor that 'whatever needs to be done, will be done' and the effort of 'ratification' would occur in a different activity stream.

Stream 2 - HF UI work - A baseline UI Design document is now published and mentioned during the meeting that took the collected audio and video taped data, coupled with results from interviews, and distilled it down to the top 50 requirements (as later prioritized by end-users) that must be considered and heeded whilst building the new system. Document audience: Designers and Developers.

It is mentioned that the requirements appropriately reflect all of a) current production needs, b) anticipated/desired production needs, and c) current industry best practices and trends. It is expected that the HF UI teams will stay in tact, but become part of the existing development design efforts from this point going forward. No questions are asked during the meeting.

Stream 3 - Development Design - Both a High Level and Low Level Design document are presented to as 'started' and under active editing. Built upon draft versions of the HF UI and Prototype results documents and coupled with the original Functional Requirements document as created months earlier, the teams actively build what they consider to be the technical plan and celebrate that all the parts are coming together in order to get actual coding started. Development teams are being defined according to component architecture needs and will include the pre-existing HF UI and Prototype teams as well. The lead Prototype Architect is announced to be in charge of all design and development going forward with each component development lead being a dotted line relationship to the Architect. It is expected that Development will begin during this next period and progress will be announced with a sub-project plan at that point. Document audience: Technologists.

A question is posed regarding the expected team composition. The Project Manager steps up to answer the question and suggests that the company is less able to extract existing experts from their production posts to than originally speculated; and so to offset this issue for now, the project will increase the number of consultants used for development until such time that more staffers are available to take over the work. It is expected that there will be five development teams with twelve people per team to perform anticipated development tasks, though it will be modified as needed through time.

According to everything known at this point, it is expected that actual development of the system will take four months, possibly five depending upon the yet to be planned test plans.

Weekly Project Sponsor meetings - Along the way, the Project Manager has been reporting status in terms of green and yellow lights based upon whether he felt things were progressing along well enough. Given the project was being managed in a project schedule and associated Gantt chart, both people felt well enough that they understood all the system level elements and had trust that the leaders in the group were intelligent and working hard.

The Project Sponsor (PS), being from a business unit in the company, mentioned during one particular meeting that she knew work was occurring and felt confident that it was good work given the teams ... but that she wondered if the documents being created appropriately took into consideration the business of the company. The Project Manager (PM) mentioned that the consulting firm is one of the best, and that software projects like this typically take a big up-front investment to make sure the right product is produced with minimized downstream rework. The PS suggested she'd like to take a look at the documents just to see what kind of work is being generated. The PM replied that he'd send them along, but that they were written for the technical folks and may not be immediately useful to the business side of the house. The PM further remarked how hard the teams were working, that some FTEs were already working fifty plus hours per week, and the project should perhaps have some additional funding for motivational social gatherings along the way. They agreed that things seemed to be going forward appropriately, deviation from planned budget was reasonable explainable to the Budget Committee, and that they would request additional monies for select motivational elements in the future.

A couple of behaviors to note:

1. Overall corporate project status is discussed monthly
2. The component architecture defines the project structure
3. The PM fields all questions regardless the subject
4. The PS is provided subjective {Red, Yellow, Green} light statusing each week
5. The PM has begun teaching the PS how software "ordinarily works" to ease concerns
6. There is an implicit behavioral expectation to "get it right the first time"

To date cost of acquisition: $1,764,800.00
(PartII=$972,800) + hw/sw + travel

To date time elapsed: 7 months
To date return on investment: 10 documents and some working prototype code

Sidenote: It turns out there is discovered a disagreement between the consulting company and the host company accounting group about when and with whom the blended rate would apply. As such, the current burn rate is privately in dispute. There is an additional lack of clarity regarding "who" is considered an expense on this project versus non-billable oversight.