People Re-engineering

Introduction

To some of us the term People Re-engineering may sound a bit unfamiliar. You may have come across similar terms like Peopleware, or you could have seen something like it in a company’s name. But what I mean here is a something different.  It is my intention in this article is to present People-reengineering as a concept that I’ve personally seen to be of prime importance in today’s development ecosystem. I landed on the value of this newly formulated idea after almost a decade of “give and take” with colleagues in the business in search of some innovative solutions to issues we meet in the software delivery process.

For decades, we were used to terms like Systems Engineering/Re-engineering, Business Process Engineering/Re-engineering (BPE and BPR) and maybe some more derivatives of that, but not literally to this one: People-reengineering. My goal is to articulate what the concept means, how it evolved and in which way it should impact the software development organization.

The Software Crisis, Revisited

Some experts don’t like talking about “Crisis Theory” when talking about the “challenges” that the software industry is increasingly facing in today’s harsh business environment.  If we look further into the yield of the industry for the last 5 years as expressed by the Standish Group CHAOS Report 2015, we should at least pause. I’ve seen debates from some expert watchers about the methodology used in gathering data and deriving results to produce this report. However, I still don’t think that there is much disagreement on the significance of the report to a wide sector of watchers and practitioners as a source of data on performance in the industry. I personally find that piece of work very representative of what I see on the ground during my daily practice.

Let’s consider the “full success” figures in the report summary – those projects that came on schedule, on budget and to customer satisfaction. This is actually what we should target and call “real success” if we are serious about what we do. In this segment of results, we find success rates across the last five years as 29%, 27%, 31%, 28%, and 29%.  This means that less than one third of what we do is successful.   Accepting such a situation is mediocrity in an industry which proclaims creativity and brightness and keeps promising that to the world. I think it’s no longer debatable to say that this is an “Industry in A Challenge”, if not in Crisis. Full discussion for the reasons behind that has been the subject of a plethora of thoughtful works by industry experts, but what my focus on here is one of the major reasons leading to the challenge: the 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 of that throws into the young minds who are supposed to achieve under such harsh situations, sometimes to insanely tight schedules!

We can summarize all these complexities into one whole, which is the emerging complexity of software development process management. We can now start some analysis from here.

Development Complexity Timeline

It’s the complexity in “managing” the software process that is challenging our success in the development business, causing the crisis or at the least the big challenge.

Look at the slide here, tracing how our process management complexity evolved across time. The starting point is the beginning of web technologies. Of course, complexity was not zero before then, but we shall start above what was there anyways, which was really fractional in comparison with today. On the curve, you see complexity taking off steeply as applications started to move to the web, with a lot of pressures on developers coming from emerging technologies, new classes of requirements, new pace and time scales for delivery as well as new “innovative” operational threats. You can see software management complexity going up from the initial point till say approx 2K (Year 2000) on the timeline. In this era we were not only net-enabling business-as-usual applications, but also the new e-anything business was born.  This new family of applications impacted not only how we develop applications, but also the way we do business. Their impact has gone further on to the way we live on the whole! Our applications became not just a goody in life, but one of its necessities. That’s more responsibilities for us to meet, Yes?

Under pressures from the new paradigms imposed by the net era, this segment in time (start – 2K) witnessed increasing difficulty in controlling what I call our {Q, P, S} vector: denoting {Quality, Productivity and Stability of human resources}. Industry of course responded by revisiting and revamping two families of resolutions, which also mark up two sub-intervals you see on the timeline as red tags:

• S.E techniques Er:, things like SDLC, waterfall and Structured Programming,  to recover our {Q,P,S}, at least in its {Q, P} elements! This didn’t work well, as it was too much predictive in an era where non-predictiveness started to take the leading role. Hence, the industry still felt the need to proceed to some more effective solutions.
• Process Era: Then came a time where our attention went to the Process not just the System (or the Product), and the industry hired the TQM process management techniques to produce things like ISO variants, CMMI and Probably PSP & TSP and maybe more, which were all employed to enhance our QPS results. There were, of course, some improvements in handling complexities, represented by a less steep segment of the complexity line on the figure after transition from pure S.E to the BPE years. But complexity went up as a result of the proliferation of technologies and the continued ambitions of software clientele together with more operational threats coming up. There was still a need for more innovative approaches.  

In spite of the desire to take the curve down on the figure, our industry still enjoyed the highest rate of turnover represented by the element S in {Q, P, S} vector. This is again a sign of growth in process management complexity.  Concurrently we faced higher risk and lower rate of full success in our projects in comparison to well-established industries.

To complicate things further, the application market was dashing faster behind a new class of applications that serve the emerging Knowledge Economy Era, whereby the application itself has managed to become the business on its own, not just “serving” the business needs! Just recall things like a booming game, mobile app or service. This is a clue to a new breed of software applications born in the days of knowledge-based economy. With this new condition a new pace and more demand were again imposed on the development process, contributing to its management complexities!

In the same time and immediately before crossing the 2K barrier on the time axis, there was a crescendo in the industry’s awareness to turn the focus to People, those in teams who do it all. Techniques to reduce their stresses and redirect their energies positively were devised by great minds in technology.   The Agile Movement and Object Oriented Development Methodology were two of the major factors in this period (starting earlier than 2K, of course). While agile development came up with a more motivating and self-actualizing work environment for development teams, OOPS targeted Reusability as a main virtue that saves any development team a hell of hours spent in re-inventing the wheel.

We came today to a state where the value of people in the process has climbed to such a point where those  doing it all must receive continued attention to keep them not only technically competent, as well as resilient and motivated to meet the challenges in elevating that QPS of the development organization as a whole. This effort is what is there to cause People Re-engineering to happen.

So, Let's Define It!

People-reengineering is a process that happens, or should be happening, inside the development organization in tandem with its main software development process.  People’s behavior is consciously and transparently monitored for continuous improvement, with the purpose of:

• Encouraging positive initiatives,
• Spotting negative attitudes and fixing, or maybe eliminating, them with the right timely and keen initiatives.

Conscious and closely attached  Leadership is the key player in achieving this state.

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

The title of this section is what you normally hear from high-paced Executives who are haunted by the financial indicators alone. In many cases these very same executives are those screaming of troubles in getting their ROI value straight  because of problems in their QPS vectors!

The slide you see right here is the answer. Where does cash flow come from? If you are productive and delivering quality that provides 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  costs of turnover: repeated hiring costs, ramp-up time losses and its associated delays for the new hires, never to forget the negative impact of high turnover on people’s morale, hence their 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 destination for craftsmen/women.

Actually, what those high-paced executives must know is that things have changed from the days 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 above in this article, to see that any software owner/executive today finds himself/herself facing a crucial decision, either to continue with S.E. and BPE/R alone, or to turn his/her  attention more towards the new era of people-centric development. The decision is yours!

Conclusion

This slide is the key message of people re-engineering. Its message is simple but very effective, you work not only on people’s competence to enhance their total performance, but you need to help them establish distinguished behavior in maturity and mastery to do what they do better, less stressfully and, hopefully, much more enjoyably.  The end result is improving your QPS vector: that’s your overall organizational performance at the end.

This concludes my introduction to People Re-engineering.  This subject has turned out to be my main passion in the development craft for the rest of my career.

A Synopsis of The “How-side”

So this was the “what-side” of the subject. Let’s debate it and maybe come down to my trials on the “how-side” in some coming article.  Until then, and if you share the belief with me, you might be interested in a preview of what’s there in that “How-side”. So, here are some highlights until we probably meet again on People-reengineering.

Actually, implementing the concept is an organizational strategy on its own. It starts at the top level leadership with some faith in the value of the organization’s human capital and not just the financial one. This is again depicted in that decision point I discussed on the timeline slide. This strategy propagates as reality into the organization’s human assets through the following main execution threads:

• Mentoring and Coaching Thread. Expressed by a new line of training entirely different from conventional formal technical or soft skills training. It comes through well-planned concise and to the point sessions of mentorship and/or coaching. This targets mainly valuable experience on craftsmanship in software development issues, defining its challenges and examining innovative and pragmatic ideas to tame them.
• Leadership Revamping and Enablement Thread. Enhancing the role of Leadership to replace the old management paradigms, especially for those leaders in direct contact with development teams: Team Leaders and Project Managers. This comes through proper interactive training, coaching and enablement. The pitfall here is to go for conventional leadership training for the purpose. Beware! Leadership is context-sensitive: Leading a Rugby Team is different from Leading a Team in Swimming Dancing. The challenges, the skills and the values are not the same in both. We must have our leadership model to meet our own challenges in order to get the true benefits out of moving to the vivid model of leadership.
• Teaming Thread. Teaming is not just a term for “working together peacefully and productively”. It actually represents a solution on its own to some of our daily chores. It has a secret called Synergy, which should be “burnt” into the team members’ mindsets. I use an Energy Model to visualize The Secret of Teaming and instill that in the minds of team members. It works better when the people build a clearer mental image of teaming and its benefits as a phenomenal change to their work lives, and maybe lives in general.
• The Executives and Decision Makers Thread. They should be invited to turn their view about investment into the Human Capital model, if they want to go seamlessly along the future of this industry. This involves awareness sessions, meetings and reviews on transformation projects results.
•  Continuous Improvement Thread. People-reengineering is a continuous process, by definition. This calls for Continuous Performance Observation and Evaluation too. The role is purely a “wise leadership” role. It’s very highly relevant to the keen contact between a leader and his/her people. If you have the proper leadership installed, the benefits will be achieved sooner than you think.

That was my intro to People-reengineering. Later, we elaborate on the How’s, the difficulties and (probably) some downsides!

About the Author

Medhat Sabry is a Software Development  Consultant, Speaker and Writer addressing the development community over his own self-constructed web-based initiative called Techstamina, together with other social media and professional networks channels. Staying there in the heart of software delivery process for nearly four decades, Medhat had a sound  exposure to the emerging challenges in the development industry that formulated his passion to help developers and companies build their professional stamina to take the ever-growing pressures and challenges in today’s software market.