Why Scope Complexity Really Matters

Why Scope Complexity Really Matters

We've all heard the term Scope Creep but this can be reduced if an accurate picture of scope complexity is realized prior to the onset.

Similar to my last post, I would like to help smaller businesses establish effective corporate governance measures to ensure successful operation. This is only intended as an opinion and to help those in need of a rough start.

In addition to time sensitivity...we should also categorize a given project based on scope complexity. As generic as that sounds, Aaron Shenhar and Dov Dvir (S&D) developed a genius way to go about this task. They categorized the Scope Complexity attribute in projects that dealt with a single business component, system projects that have interactive inter-component relationships, lastly, and most complex are array projects which have many established up-stream, down-stream as well as potentially cascading impacts. 

 I believe the most efficient and effective model that would be applicable to the majority of projects faced in today’s time would be S&D if time sensitivity would be added as a third attribute. I considered requiring organizational design as another attribute and choose not to incorporate it since this would be partially uncovered by the other three attributes and although it might be a nice piece of information to have in advance, it will be rare that it will single-handed add actionable information to the capture management process. In a time where blue ocean technologies are now being explored, the S&D typology is the simplest and yet most predictive as in providing actionable and clearly definable categories. Technological uncertainty is quickly catching up with urgency as a project attribute of noticeable importance. 

Array projects are typically so big and transformational that strategic thinking is absolutely critical in order just to establish logical milestones and to ensure that the right people are involved, informed, affected …etc. Additionally the scope complexity attribute, as they defined it, could be applied to applied to cost estimation due to the types of activities that become necessary to successfully pull off a project of that magnitude. 

Lastly, I would propose one additional project profile attribute that isn’t on their list (other than time)… if this project is an array or system scope complexity level project… then the project management firm should make every effort to ascertain if the project needs to be completed concurrent to day-to-day operations in real-time or if the project has an exclusive development environment that is separate from the deployment phase; since this can drastically affect the planning involved in such daunting projects. If daily operation is critical to business continuity, then maintenance / deployment / project work windows need to be scheduled and could drastically affect the time sensitivity requirement. This attribute should only be mentioned if the project involves business processes or technologies that cannot go offline without causing significant damage to the client’s organization. And damage should not solely be defined financially because brand image is an extremely difficult and often costly thing to rebuild in the eyes of a client / customer.

Thank you guys for the continued support, hopefully one day I will find myself in a strategy meeting with the ability to impact change in a positive way personally!

Keith Whiteman

President/Founder at Technology Management Solutions

8y

Very helpful

Like
Reply

To view or add a comment, sign in

Insights from the community

Others also viewed

Explore topics