Sample Contents - Timing Is Almost Everything - a new book about software management success

TIMING IS ALMOST EVERYTHING -- SYNOPSIS

Introduction

The introduction opens with an inquiry to the reader asking if he is the right person to read this book by sardonically inquiring if he is bored because his projects are running too smoothly.  It briefly explains that the book contains the tools to improve the returned business value of a software project, noting that executives are typically disappointed in the resulting business value of software projects.  It then explains that the text is a handbook that gives hints about the best time to preempt disappointment and shows non-technical ways to do that intervention.  It explains that those ways are similar to ways he improves the return on value in non-technical areas of his life.  The book calls these ways "management by query."  The book architecture is outlined as two parts requiring no special prerequisites.  Part One is questions to ask a software team.  Part Two is ways to take remedial action if the answers to the questions reveal issues to be handled. CLICK HERE TO DOWNLOAD SAMPLE.

PART 1 -- THE EXECUTIVE ROLE

Chapter 1 -- Does the Past Lie to You?

The chapter opens with a scenario of a CIO presenting to a top executive an expensive software project plan. It notes that past failures of software projects can come from an incomplete list of questions at the beginning of the project.  It describes the historical question set that executives have often asked.  A reason is presented for why software is intrinsically very difficult.  Based on that reason, it then shows how asking new, hitherto unasked questions can overcome these difficulties because the new questions implicitly change a software team's behavior into a more effective way of working.  The chapter explains how asking questions can be more effective than simply propagandizing new rules and procedures of software quality for the team to follow.  The chapter concludes with provocative introspective questions to the reader that begin to subtly point the reader into a new way of thinking about how to get better business value from software projects. CLICK HERE TO DOWNLOAD SAMPLE.

Chapter 2 -- Restoring Your Power with a Velvet Glove

The chapter starts out with a scenario of the reader buying a resort cottage and using the cottage floor plan to determine whether the cottage offers good value for the money.  Using an intentionally flawed floor plan, the text demonstrates how the reader uses the floor plan to discover in real life the flaws in value of the cottage.  The text goes on to show a simplified company Human Resource software project "software floor plan."  The text then shows how questions similar to those asked about the cottage can have the power to improve the business value of the Human Resource project in a way that is different and more long-term effective than typical executive command directives. The most appropriate time to ask these questions is underlined.  The text then gives eight questions about the internal components of the system that the executive can ask.  The text shows sample, easy to understand answers that a good software team will respond with.  Some follow-on questions are given if the responses are not so good. The chapter concludes with provocative introspective questions to the reader that continue to subtly point the reader into a new way of thinking about how to get better business value from software projects.

Chapter 3 -- More Glove Work

This chapter describes two more questions and answers.  These are are ones that are about the company's software building process rather than the project features or internal components.  It describes the value of building the system in very small pieces one at a time and gives important hints about which pieces should be timed to be done first.  The chapter explains why this particular timing of building pieces can prevent a lot of disasters.  The chapter concludes with provocative introspective questions to the reader that continue to subtly point the reader into a new way of thinking about how to get better business value from software projects.

Chapter 4 -- Where Are We Now ?

This chapter helps the executive to get the project off to a good start by showing the questions to ask to determine if the project is complete enough to risk funding it.  The chapter examines the seven core elements of a software project and gives commonsense ways of appraising whether each of those elements is sufficiently solid and ready to warrant spending real hard money. The core elements are explained and their aspects of readiness detailed.  The chapter gives hints for remediation if some of the elements are lacking and discusses trade-offs and recommendations that might be necessary in special situations.  It ties these concepts into the ideas of the earlier chapters.  The questions it proposes are executive simplified derivatives of a current software industry technology and standard called SEMAT Essence. The chapter gives some hints about how to put Essence to other uses if this initial exposure is intriguing. The chapter concludes with provocative introspective questions to the reader that continue to subtly point the reader into a new way of thinking about how to get better business value from software projects.

PART 2 -- MAKING SUCCESS HAPPEN

Chapter 5 -- Assessing Your Team's Anarchy

This chapter helps the executive discover, in an objective way, how easily his software team will absorb the new directions and procedures that might be needed as a result of executives asking the questions of the first four chapters.  A special series of test evaluation questions is provided which probes the company's software development practices environment.  The scoring of the evaluation produces a rating score which describes the current software team's level of inefficiency, called the anarchy level.  The chapter discusses the implications of the various score possibilities and compares them to the scores of other companies that have taken the test.  The chapter shows how how high anarchy scores and exactly predict the specific ways in which the software team is likely to fail in the next project unless some changes are made. The chapter concludes with provocative introspective questions about these scores which, questions that continue to subtly point the reader into a new way of thinking about how to get better business value from software projects.

Chapter 6 -- Dissolving Team Anarchy

This chapter takes the result of the scores from Chapter 5 and shows how to properly time interventionist tactics to remedy the inefficiencies shown by high anarchy scores.  It gives the reader some questions to ask about what might have prevented the software team from self correcting these inefficiencies over time.  The chapter suggests likely reasons for failure to self correct and ways to remediate them.  It discusses some likely vocabulary among team members that needs refinement.  The chapter concludes with a special "programmer only" advisory section that helps the programmer/coder deal with panicked schedule driven managers.

Chapter 7 -- Enhancing Your Software Power by Exercising It

The chapter explains that after software team inefficiencies are removed, the way in which the non-technical executive exercises software leadership is the single most important factor for bringing about the changes required to improve software project success. It explains what those ways are.  It explains the importance of leadership that is sustained over time.  It explains how that leadership is supported by a formally thought out and implemented set of marketplace benefits and internal programmer benefits that will happen when the changes are adopted.  Sample non--routine benefits are provided as beginning guidance to prod the executive's thinking.  Some subtle communication techniques are provided.  The chapter also provides an ongoing way to test whether the leadership tactics are continuing to be effective, solid and sustained.  The chapter concludes with some introspective questions that help the reader identify unique rather than the usual routine benefits resulting from reducing software team inefficiencies.

Chapter 8 -- Putting It All Together: Tips and Tricks

This chapter gives guidance about how to tailor the book ideas for a variety of special cases, for example, choosing a new project versus a project that is already well along.  It also gives insight into personnel reward schemes which help make insertion of the book ideas flow smoothly.  It reviews the best way to time the leadership tactics, ways to think about return on investment for some of the book ideas, and how to prepare for the likely volatility of project software features as project development progresses.  It briefly reviews the positive impact of some of the book ideas in other companies.  It concludes with a reminder to plan ways to celebrate a software project success, ways which continue to enhance executive leadership.

Chapter 9 -- Conclusion

This is a brief chapter which reviews what the book provided to the executive: an understanding of the particular difficulty of software, unique questions that subtly shape the team's way of working to deal with that difficulty, timing tactics for asking the questions, timing tactics for changing the corporate environment to support the questions, jargon free monitoring tools for software progress, an objective way to diagnose software development process inefficiencies.  It concludes by asking the reader imagine for himself exactly what software project success would look like and to rate how much he wants that success.

Appendix 1 -- Improvisations on the 10 Executive Questions

For each question mentioned in chapters 2 and 3, several verbal variations are presented for an executive to use so that he need not feel constrained or stilted in real conversations with the software team.

Appendix 2 -- Anarchy Questionnaire

A list of the 21 questions which probe and rate the efficiency or anarchy of the software practices of the team as mentioned in Chapter 5

Appendix 3 --  Risks for High Scoring Questions

Each of the 21 questions has business risks if high inefficiency is revealed by that question.  This appendix looks at each question and discusses what unhappy things are liable to happen to the project if the executive ignores that high inefficiency score and takes no action to remedy it.

Glossary

A somewhat whimsical explanation of the major software terms used in the book to help a non-technical executive. It includes the terminology also used by the Essence core elements discussion of Chapter 4.