Trends: Information Technology is Self-Destructing

I have been in the Information Technology field a long time. Maybe too long… close to 35 years.
I have been through the fads, the whims, the hype, and host of other trends that have come and gone with barely a whimper. Yet, the trend I am starting to see does not appear to be one that will go away but seemingly become worse over time.
Information Technology, a scientifically based discipline that requires a professional developer’s “creative juices” as much as it needs their penchant for logic seems to be running aground quite rapidly on all the hype that promotes this field as nothing more than a commodity to be used for the increasing irrational requirements of business people that have historically lived in alternate realities as to what is possible and what isn’t.
A case in point is the article below from gantthead.com, which details the experience of one technical manager trying to meet an irrational deadline promoted by a committee completely disassociated with the realities of their own requests.
There was a time that the very nature of Information Technology dictated such terms to its “masters’ but today, with technology changing at increasingly dizzying speeds, the concept of rational project planning has seemingly slipped off the radar. This event, though always a common factor in the field, has been encouraged ever more so by the commoditization of such technology to the extent that many technical managers themselves view the implementation of critical processes as nothing more than a simplistic act of writing some code and restricting testing to the thinnest of timelines.
Business talks a great line how they want professional technicians to come to the table with new ideas and enthusiasm but the reality still seems to be what they really want are “boiler room” people to keep shoveling coal into their aging furnaces.
Hand in hand with all this seems to be a growing comprehension problem on the part of younger and even some older managers when reviewing emails, documents, or even resumes.
My current supervisor is always exhorting me to write shorter emails to the point that they would mimic his which are nothing more than grunts with words. I find it perplexing that as our technical environments become ever more complex the requirement for comprehending that complexity should be reduced to nothing more than snippets of information; a reflection of the fact that some sociologists are calling American society, the “PowerPoint” society with PowerPoint being the digital re-incarnation of the overhead project, neither of which were capable of transferring any in-depth information.
Today the world is moving faster and faster with the expectation that professional technicians are expected to keep pace with an increasing burden of traumatic information overload while at the same time be capable of reflective thought processes that will generate sophisticated computer processes.
Business people all think that everyone can keep up as they continue to ratchet up the pace of development efforts and vendors are only too happy to promote such fantasies as they produce increasingly complex tools with the idea that now that you have the power you can create bigger, more complex, and better applications than before. The result is that technicians know a lot more detailed “junk” but have begun to lose their capability of designing rational systems that process well.
Indian technicians and managers seem to be known for this dichotomy as they have an inordinate capacity to absorb highly detailed pieces of information but little understanding as to how it should be used appropriately.
Every system I have worked on that has been overseen by Indian managers, with the exception of one who had an intimate knowledge of software engineering standards, has been nothing more than a hodge-podge of fixes and band-aid approaches for the resolution of technical issues. The excuse is that there is no time for what was once called “rational thought”. And yet these same people are highly intelligent and capable of understanding the minutest of technical details. And that is their biggest problem; they can’t seem to see the forest through the trees anymore.
American technical managers, though a little more thoughtful, have never been known for this level of capability. And this is probably the main reason why so many Indian personnel have replaced them in the business end of the Information Technology field. They can make things sound so much better than they really are.
While American corporations are happy to send their jobs overseas or exploit the Indian and other foreign personnel that come to the United States, the end result will be that they are gutting the very industry that made the United States a modern economic powerhouse while playing fast and loose with every other aspect of the international economic environment.
The old adage that “Everything American business touches turns to crap…” is bearing fruit in this realm…
| Planning Around Uncertainty Mark Mullaly, PMP May 27, 2008 |
The more uncertain the world becomes, the more we seem to value guarantees and absolutes. Nowhere does this appear to be truer than on our projects. While projects have become larger and more complex, the expectations being placed on them are progressively more demanding, particularly with respect to the cost and schedule associated with getting them done.
Project sponsors and steering committees want precise and accurate commitments of completion and cost, even while they acknowledge that there may be limiting or constraining factors on the project. Although project managers recognize the improbability of plans, we find ourselves accepting the mindset being imposed and presenting conclusions even where we know or fear they are unrealistic and unlikely.
Why do we allow ourselves to accept a version of reality at odds with what we know to be true? What can we do to more confidently present our projects and our estimates when we know–or at least strongly suspect–that there is a high level of risk that our estimates aren’t completely accurate given the variables?
Let’s deal with the question of why we allow ourselves to get bought into an approach that we know we can’t support. As project managers, we have all at some time in our careers done this, and often have lived to regret it. We go into a steering committee or a meeting with our sponsor, and allow our logical position and objective arguments to be compromised to the point where we accept something we don’t believe can happen. Why do we do this? Where did our logic and our resolve go?
Much of the answer lies in human nature. When we develop plans and estimates, they are our best attempt to quantify and define what needs to happen in conducting the project. As the developers of those plans, however, we know they are fallible. We recognize that they are based upon assumptions and approximations and have a number of risks and unknowns built into them. As a result, when we are challenged, we give credence to the challenge–there is as much potential for the challenger to be correct as we are.
As well, we are conditioned to help and support our customers and sponsors. This means that when we have a clear understanding of a required outcome–or a desired date or budget number–our tendency is to figure out how the project can be done within that constraint. Often this involves hoping for the best, assuming out all of the potential pitfalls and issues and committing to a number that is only possible if absolutely everything goes right and absolutely nothing goes wrong. Unfortunately, recognizing the role that Murphy’s Law plays in a project environment, problems will inevitably emerge, and with them our estimates are left in tatters.
Finally, the challenge rests in the degree of confidence we have in our own role, pitted against the determination (or aggressiveness) of our sponsor. Project managers by their nature rely on influence and persuasion to attain most of their outcomes. Rarely do we have the luxury of exercising power and authority, because we are not often in a position in the organization that wields significant authority, at least relative to our sponsor. The result is that even though each of us plays project roles, our organizational roles and the power associated with them also get asserted. The organizational seniority of our sponsor and steering committee means that it can be difficult or impossible for a project manager to confidently hold their ground in the face of an imperative from a superior, even where that imperative is wrong or at least unrealistic.
An example of this occurred recently on a project that I was supporting. The project manager had worked through the detailed planning of a complex, comprehensive process improvement project that also had a significant component of organizational change. The project work was involved, required a high level of cooperation and participation from staff throughout the organization, and had a number of interdependencies and linkages within the work that meant that each component depended upon the completion and quality of the work that came before. A very public commitment had been made around the delivery date of the project, and the sponsor and steering committee member were absolutely determined to ensure the date was met.
To be able to meet the date, careful consideration was given at the outset to what scope could reasonably be accommodated. Delivery of that work, however, required a dedicated and concerted effort by staff from throughout the organization. The project manager gave their best effort to ensure the project could be done on time, but deliverables started to slip and schedule dates got missed. They communicated the slippage to the steering committee on a regular basis, but although the steering committee had all of the information to recognize that the project could not deliver on time, they refused to accept the reality and became more vehement that the date would be met.
In the face of objective evidence, there was incredible pressure on the project manager to buy into and accept an alternative view of reality that didn’t add up in practice. It was only shortly before the end of the project that the schedule finally got pushed back, and a revised date that was actually possible became accepted.
So how can this situation be avoided on other projects? Even though the project manager made every effort to keep the steering committee abreast of actual progress, there was an inherent unwillingness to hear any answer but the one that they wanted to hear. The result was that everyone on the team–including the project manager–made a herculean effort to do what many knew was impossible. A lot of overtime and a considerable amount of stress in no way changed the outcome that many expected and believed was inevitable.
The biggest challenge is in getting sponsors and steering committees to recognize reality for what it is, and to accept what is possible and what is not. Part of our culture seems to embrace macho, heroic efforts to deliver on the impossible. While stretch goals can be motivating, what research has demonstrated is that “stretch” is a 5 percent reduction, not 25 or 50 percent or more. Ninety-five percent of a realistic schedule is considered stretching, while anything less than that will be widely viewed as impossible (and typically is unfeasible without excessive overtime, compromises in quality and negative impacts on other personal and work commitments).
What is required to change this outcome is to ensure that all stakeholders have an objective view of reality. Project sponsors and steering committees need to have expectations set up front that all projects have risks and uncertainties, and it is normal and expected for a project to encounter some form of challenge before it is delivered.
Equally important, however, is that sponsors and steering committees must recognize that their project roles and decision-making responsibilities are separate and distinct from their organizational authorities. The status of senior vice president does not come with the authority or ability to bend the laws of time and space to create a 28-hour day in place of the normal 24 hours that we mere mortals live with. Simply wanting something to be so does not make it so.
Setting these expectations up front is one part of the process. As well, we need to maintain confidence in our plans and in our estimates as the best reflection of what we believe is required to deliver the project. We need to be willing to be honest and impartial with our sponsors and steering committee members regarding what is achievable and what is not. What this means is a change in how we present project plans.
A tempting reality for many project managers, as noted earlier, is to “assume away” the risks and problems of the projects. The list of assumptions becomes the necessary (and optimistic) preconditions for the project to be successful. Read a different way, however, and the assumptions become all the likely risks and problem areas that will cause the project to falter or fail. Rather than downplaying these risks and challenges, however, we need to clearly present them as what they are–impediments that will prevent the project from being successful if they occur.
Project managers must encourage their steering committees to objectively understand the actual circumstances of the projects they oversee and help them to craft the stories that allow them to communicate the project status to the rest of the organization. We need to refuse constraints and limitations where doing so means the project will be unsuccessful, and find a way of doing so that is still seen to be constructive.
This is not always easy, and at times may feel like a career-limiting move. In some instances, it may in fact be one. What we need to recognize and remember as project managers is that where our views and recommendations do not have the backing of our sponsors and steering committee members, or where we feel pressured to accept visions of reality that are at odds with the facts, we are unlikely to be successful. Enabling the behavior only delays and exacerbates the situation. Where this is the case, it’s highly probable that we will seek alternative environments that offer greater support.
The alternative to being an objective and honest broker of project information is the continued collusion and self-deception that leads to the stress and anxiety associated with impossible deadlines and unrealistic outcomes. The only way to change this outcome is to accept that change is possible, but only if someone makes the first step. If things are going to be different, it’s up to us to make that step.
About this entry
You’re currently reading “Trends: Information Technology is Self-Destructing,” an entry on TECH NOTES
- Published:
- May 29, 2008 / 11:45 pm
- Category:
- Industry Trends
- Tags:
No comments yet
Jump to comment form | comment rss [?] | trackback uri [?]