Saturday, 15 August 2009 00:00

Extensibility

Rate this item

(0 votes)

Yes, I am on that soapbox. Ensuring that maintainability and adaptability are part of a system is a "best practice," extensibility is not. To the extent that a highly structured system is extensible, that is the end of any commitment to building for the future.

Adding hooks and stubs for something that may not happen, confuses and clutters the design of the resulting system. Building and running prototypes wastes time. Making a system extensible adds significant undefined scope. The reason is that no one knows what the future will bring. Furthermore, how can it be tested if the systems it is interfacing with are not defined?

This is one of the better philosophical underpinnings of the Agile methodology. Do not build for the future. Jim Highsmith said it well in his book Agile Project Management, "Simple design means valuing adapting over anticipating. This means designing for what we know today and then responding to what we learn in the future." Build a clean structured product and refactor components to account for current changes, however, leave the future for that, the future.

Leaving room in a hardware design for extension (i.e. ensuring the interfaces have expansion room) or ensuring software has the capability to adjust to areas known to be volatile, is perfectly sensible. Consideration for some yet-to-be-defined standard is over complicating and adding time to the design, additionally building and testing something that may need to be completely thrown away and rebuilt.

Too many engineers want to make their system fit the future by anticipating where and how the system may be used in the future. This is often hidden in what is simply referred to as "implementation details". The project's management and even the customer are left out of the decision. However, this is a huge area for internally induced scope creep, additional risk and increased cost. This is a recipe for project failure.

Anticipation should be for areas of known change. Even this should be clearing called out so that the project team and the customer understand the work involved in its design and implementation. If they choose spent their time and money in others areas, that is their choice. The Project Manager will need to work with the technical team and their functional managers to instill this philosophy.

Read 9563 times

Tagged under

Related items

Filling Execution Gaps: How Executives and Project Managers Turn Corporate Strategy into Successful Projects

What Filling Execution Gaps Covers

Filling Execution Gaps

by Todd C. Williams
ISBN: 978-1-5015-0640-6
De G Press (DeGruyter), September 2017

Project alignment, executive sponsorship, change management, governance, leadership, and common understanding. These six business issues are topics of daily discussions between executives, middle management, and project managers; they are the pivotal problems plaguing transformational leadership. Any one of these six, when improperly addressed, will hex a project's chances for success. And, they do—daily—destroying the ability companies to turn vision into value.

Check it out on Amazon or the Filling Execution Gaps website

Without the foundation of a common understanding of goals and core concepts, such as value being critical to success, communication stops and projects fail.

Without change management, users fail to adopt project deliverables, value is lost, and projects fail.

Without maintaining alignment between corporate goals and projects, projects miss their value targets and projects fail.

Without an engaged executive sponsor, scope increases, goals drift, chaos reigns, value is lost, and projects fail.

Without enough governance, critical connections are not made, steps are ignored, value is overlooked, and projects fail.

Too much governance slows progress, companies cannot respond to business pressures, value drowns in bureaucracy, and projects fail.

Without strong leadership defining the vision and value, goals are not set, essential relationships do not form, teams do not develop, essential decisions are not made, and projects fail.
Kill The White Knight
There is a reason we hesitate to teach classes on fixing failing projects. Many a cynic feels that we simply do not want to teach our trade, however, our reason is far nobler—we should be teaching prevention rather trying to create white knights to save the day. It is the same philosophy as building a fence at the cliff's edge rather than an emergency room at its base. Our language is replete with idioms telling us to look past the symptoms and address problems at their root cause. 'An ounce of prevention versus a pound of cure' or 'a stitch in time saves nine.' Please, feel free to supply your own in the comments. Unfortunately, most of our businesses loathe this philosophy, waiting to address an issue until it is irrefutably broken.
IT: We Don't Need No Stinking Leadership
I have never posted email marketing results, because... well, let's face it... it is kind of tacky. Now and then, however, there is a story to be told. In my opinion, this set of statistics is a little over-the-top in what it shows. I can only see one way to interpret it other than Information Technology "leaders" simply do not care about leadership.

To understand how I can make such a brash statement, you need a little background...

Alignment: Using the Balanced Scorecard to Create Corporate Synergies

**Alignment: Using the Balanced Scorecard to Create Corporate Synergies**
Add To Cart
Author:	Robert S. Kaplan, David P. Norton
Publisher:	Harvard Business Review Press
Released:	April 2006
Type:	Hardcover
Pages:	320
ISBN:	978-0201835953

Projects build capabilities to met corporate goals. If you are a CEO, you need to make sure your employees and vendors know what those goals are and how they fit in to the plan. If you are a project manager, you need to know the bounds of you project. If you are anywhere in-between, you need to understand how all the pieces fit together and keep it all aligned.

Most organizations consist of multiple business and support units, each populated by highly trained, experienced executives. But often the efforts of individual units are not coordinated, resulting in conflicts, lost opportunities, and diminished performance.

ADKAR: A Model for Change in Business, Government and our Community

**ADKAR: A Model for Change in Business, Government and our Community**
Add To Cart
Author:	Jeffrey M. Hiatt
Publisher:	Prosci Learning Center Publications
Released:	August 2006
Type:	Softcover
Pages:	146
ISBN:	978-0201835953

This book is currently under review, more details will be added when available

Tired of hearing about change and how your project is implementing it, but have no idea how to make it happen? ADKAR is the gold standard process to follow to help make that happen. This, and a little leadership, will get you ahead of the pack.

Why do some changes fail while others succeed?

How can you make sense of the many tools and approaches for managing change?

How can you lead change successfully, both in your personal life and professional career?

More in this category: « CIOs Are Fired For Failing to Provide Business Value IT: We Don't Need No Stinking Leadership »