The Era of People Re-engineering



The People Re-engineering is surely new to your ears, though you may have heard that as something like Peopleware, or as a firm’s name rather than an industry term indicating a concept. We are all used to terms like Systems Engineering /Re-engineering, Business Process Engineering/ Re-engineering or (BPE and BPR) and may be some more derivatives of that, but not this one. In this article, I try to articulate what the new concept means, how it evolved, and in what way it should affect the software development organization.

The article is based on a presentation I used to give on the concept to software executives, where I’ve selected the key slides for display here, combined with the relevant comments and/or explanations. Take It as a printed briefing presentation, more or less!

The Software Crisis, Revisited

The table above presents a yield of development industry for the last 5 years as expressed by the Standish Group CHAOS Report 2015. There could be debates from some watchers about the methodology that the Standish people are using to gather data and derive results, but to me and to a wide segment of this cult the report is still the most significant source of data about how we are doing in this industry. On the other hand, I personally find it very representative to what we see on the ground during our daily practice.

So, if we look deeply into the “full success” figures (on schedule, on budget and to customer satisfaction), which should be the target of any serious operation  here, we find that we are an “Industry in A Challenge”, if not in Crisis. We are struggling to keep our full success rate at 30% of what we do. Full discussion for the reasons is beyond the space here, but let me summarize that as an increasing complexity of the type of applications we do, the technologies we use, the threats we meet and finally and most importantly the stresses that all that causes on the young minds that are supposed to achieve under all that, sometimes in insanely tight schedules!


Development Complexity Time Line

So, it’s complexity in managing the software process that is challenging our success in the software development business, hence the crisis or, in the least, the challenge.

Look at the slide above, tracing how this process management complexity evolved across time. The starting point is the nascence of web technologies (complexity was not zero before it of course but we shall start above what was there anyways, which was really trivial in comparison), where applications started to move to the web, with a lot of pressures on developers coming from new technologies, new class of requirements, new pace and time scales for production as well as new operational threats. You can see that complexity is going up from the start till say approx 2K (Year 2000) on the timeline. In this era, as well as net-enabling usual business applications, new e-anything business was born, to mark the impact of how we develop applications not only on the way we do business, but also on the way we live.

Under pressures of the new paradigms, this segment in time (start – 2K) witnessed a difficulty in controlling our {Q, P, S} vector: denoting {Quality, Productivity and Stability}, which called for revisiting and revamping two things, that represent two sub-intervals:

  • S.E techniques, things like SDLC, waterfall and Structured Programming,  to recover our {Q,P,S}, at least in its Q, P elements! This didn’t work fine as such, as it was too much predictive in an era where non-predictiveness started to take the leading role. Still we felt the need to proceed to some more penetrating solutions.
  • Then came a time where our attention went to the process and we hired the TQM process management techniques to produce things like ISO variants, CMMI and Probably PSP and maybe more, that were deemed to enhance our QPS results. There were some improvements, represented by a less steeper segment after transition from S.E to BPE years. But complexity went on thirsty for more to do.

In spite of that, our industry still enjoyed the highest rate of turnover represented by S in QPS vector, with that low rate of full success of its projects in comparison to well-established industries.

To complicate things further, the application market was dashing faster towards a new class of applications that serves the emerging Knowledge Economy Era, whereby the application itself could be the business, just recall things like a booming game, mobile app or service.

In the same time, and immediately before and crossing 2K barrier, there started to be some awareness for more need to turn the focus to people, those who do it all. Techniques to reduce their stresses and redirect their energies positively were devised by great minds in technology. Ahead of all came Agile Movement and Object Oriented Development Methodology (starting earlier of course) which targets reuse as a main virtue that saves any development team a hell of hours spent in re-inventing the wheel.

In my thinking, as a close observer to development arena, we came today to a point where the importance of people has climbed to a point where they must receive a continued attention to keep them not only technically competent, but (and above that) resilient and motivated to meet the challenges in elevating that QPS of the development organization. This effort is what I here call People Re-engineering.

So, Let's Define IT!

It’s a process that goes in tandem with the main production process of the organization, through which people’s behavior is consciously and transparently  monitored for improvement, with the purpose of encouraging positive initiatives, spotting negative attitudes and fixing them with the right actions.

The fact that is never to drop is that conscious and closely attached  leadership is the key player in implementing that.

 Aha, Not Me, I’m a “Show me the cash” Type of Person!

The title of this section is what you normally hear from high paced leaders that are haunted by the financial capital indicators alone. They, the very same people, are usually screaming of troubles in getting their ROI value straight  because of problems in their QPS vectors.

The slide you see right above is my answer. Where does cash flow come from? If you are productive and delivering quality up to your customer satisfaction you get your money in time. That’s cash flow. And, if you enhance your people stability (the S element), you reduce the huge  losses of turnover: repeated hiring costs, ramp-up time and its delays for the new hires, never to forget the lateral impact on people morale, hence quality and productivity.  One thing that is also a definite loss here is the branding of your organization as a ”turnover company”. You become an undesired destinations for craftsmen/women, rendering your turnover and hiring process a real mess.

Actually, what those high paced executives must know is that things have changed from the time they were entering business. Thinking Human Capital, and not just Financial Capital, in this industry has become more important than ever before. Look at that point called “Today” in the timeline slide  in this article, to see that any decision owner in software today finds herself facing a crucial decision, either to continue with S.E. BPE/R alone, or to turn his attention more towards the new era of people-centric development. The decision is yours!


To me, and as I’ve seen to my audience too, this slide seems to be the master scene of the whole show. You work not only on people’s competence to enhance your QPS vector, but you need to help them establish maturity and capacity to do what they do better, less stressfully and, hopefully, much more happily.

This concludes my introduction to People Re-engineering, the underlying concept for my trials to help industry worriers take its challenges. Next on Techstamina content, we will come to a destination on how People Re-engineering can be implemented. Just please keep tuned to the site's what's up section.

It's more than welcome to write to me with any impressions/opinions/comments, pro or con, in what you have seen here.


This email address is being protected from spambots. You need JavaScript enabled to view it.