Joined :
31 January 2012
Blogs :33
Monday, 29 July 2013
5/5 (2 votes)
I've Never Seen it Work That Way

 strategy-10

 Back Story

I was recently teaching a Macroscope Foundation course, and sharing my zeal with the principle that the business participants should take a driving role on many aspects, when one person finally spoke up with, “I have never, ever seen it work that way.” In his experience, it had always been IT (and IT consultants) pushing everything.

I gave two quick answers:

  • Nothing gets into Macroscope unless it has been proven in the field – proven to work in at least some particular situations. And if it no longer works, it gets updated – driven by field experience.
  • And I gently mentioned that I had witnessed the principle of business system management in action many times myself, always with successful outcomes. (I feel another posting coming on – later.)

As I afterward mulled over the exchange, I recalled that on many other occasions, I have been questioned about something in Macroscope because the person had never seen it in anywhere else.

So I realized we need to more strongly promote the thought leadership that is imbedded in Macroscope.

Thought Leadership in Macroscope

With the evolution of IT practices over the decades, it is now very rare to find any two established schools of thought that actually contradict each other. You will frequently find different authors using different terms for the same concept, or promoting a narrow subset of the wide body of knowledge – but I personally have never seen any substantial differences out there in recent years.

Instead, you have always been able to find in Macroscope significant things that don’t appear elsewhere very much. Often things have been published in Macroscope long before becoming “main-stream”. Here are some examples:

  • Since the 1980s Macroscope (under various names) has always encouraged us to “manage by deliverables” (the language has varied). This means we first select our useful work products and then create our work breakdown structure with mostly deliverable-centric activities. The first version of PMI’s PMBOK made absolutely no reference to work products. Its approach to the WBS was based purely on activities. But if you look at the PMBOK today – it does indeed encourage a focus on work products before creating the WBS.
  • The Macroscope vision of an information system has always been that of a “business system”. Many other frameworks (I won’t put any names in print) deal only with automated components. Some of these unnamed other frameworks are evolving to include more of the business system perspective, but I am often surprised by the amount of “tunnel vision” that still persists out there.
  • The early versions of ASAP made little mention of the need to manage organizational change. In 2009, the span of ASAP was extended to include OCM and other things. But Macroscope has incorporated OCM concerns, activities and deliverables since 1991.
  • Since the earliest days, Macroscope has offered the construct of a Facet – a subset of the information Subject – to help keep the information architecture stable and useful. I recently searched for this topic on the net – and I found quite a few references to the same construct – but by many different names. So the notion isn’t main-stream yet, but is emerging.
  • But there is one highly useful aspect of Macroscope that doesn’t seem to have been imitated elsewhere yet. It’s the Results Chain technique the Macroscope team invented. Even though The Information Paradox, (http://www.fujitsu.com/ca/en/news/publications/books/ip.html) first publicized the RC technique in 1998, I’m not aware of any other framework that integrates this approach the way we do within Macroscope. We do hear about a few university professors who have discovered and teach the technique, and you will find other published schools of thought (e.g. SPIN selling) that have a similar conceptual foundation – but that’s it.

 

I gave some historical examples for credibility. Time and time again, Macroscope has published important content long before it has become fashionable. Sometimes this has been by astute selection from the public domain; sometimes it has come from our own invention.

Macroscope has never been “an implementation of … (name your favorite framework”. It has always been focused on our needs – our particular way of operating – for those of us who have signed up to use Macroscope. But when other frameworks become popular (e.g. the PMBOK) – the Macroscope team adds features to make it easier to recognize the congruent aspects. And often they will be inspired to add features to Macroscope when they see something else valuable out there.

No methodology will ever be complete. No methodology will ever be perfect for all situations. And there is material in other frameworks that isn’t yet covered in Macroscope.

So to keep Macroscope relevant and useful, we need to keep improving it – continuously. “We” means all of us who use Macroscope.

We should use the Discussion tab for specific components. And for broader topics we can contribute toward the next version of Macroscope by posting here. I look forward to many postings.

2797 view(s)

Comments   

 
0 #9 Claude Bernard Diesse 2013-11-15 20:48
I googled and stopped on this thread, and while reading it, I noticed Ed's propositions for change in Macroscope. Maybe I didn't catch all his motivations and justifications, but I really din't like it.

Ed wrote:

One thing I would change though is the following:
Owner (Business) Requirements
User (Functional) Requirements)Ch ange this to User (System) Requirements as there are functional and non-functional requirements pertinent at this level and this ties in within the renaming that has occurred between V4.8 and V5 of the P230S User Alternatives to P230S System Alternatives and P240S User Principles to P240S System Requirements.
Developer (Technical) Requirements)Ra ther than Technical requirements I would prefer to see component requirements, or design requirements. I say that because I want people to move away from saying Functional and Technical Specifications.
When it comes to requirements, or hierarchies within a System, I tend to think in terms of:
Business Requirements
System Requirements [and then System Architecture/De sign]
Subsystem Requirements [and then Subsystem Architecture/De sign] if required to further breakdown a complex system
Component Requirements [whether software, hardware, or …] and then Component Design.


What I understand in the change proposition (sorry if i misunderstood it), is the desire to see and present the project artifacts exclusively in terms of technology oriented concepts, obstructing users terminologies.

The PRIMARY and FUNDAMENTAL principle that amazed me, and make me see Macroscope as a famous modeling tool, is how it clearly distribute the responsibility and role thru the development process. The distinction between the Owner, User and Developer is IMHO, the reason we see Owner responsible of business spec via his requirements, user responsible of functional requirements and developer responsible of technical requirements.

Yes Tom is correct when he say anyone must take leadership in his responsibility field. Even if a developer (IT consultant) because of multiple projects expertise, can help in different areas of responsibility, he must give back the leadership to the owner and the user. He do this by :
  • let user validate and re-appropriate the specs
  • respect and use the user terminologies
  • explain his technical requirements to user
  • etc, ...


Projects failures are in most case cause by the lack of rigorous application of this principle. Not only due to the IT members taking all the lead, but also due to the organization members not taking their responsibility.

Concerning the statement about requirements and hierarchies within a System, the proposition tend to assimilate the Architecture phase of Macroscope, to a solely technology oriented process. In fact, in most projects out there, the success key factor reside in :
  • functional requirements completeness and content quality
  • Processes and use cases specification
  • System model for processes/use cases Realization

All other artifacts are more or less important depending of the project type as Serge correctly explained before.

Just my which to share my though on the subject.

Regards,
 
 
0 #8 Serge Deschamps 2013-09-11 13:23
Thanks Ed - I'm glad you appreciated my response :-)

Note that I used v5.0 on purpose in my explanation, as this is the current 'production' version. Since this is a public blog space, I preferred using what would be available to users as a reference.

** And the use of parentheses in the deliverable names is my bad - and you're totally right on that account e.g. User Requirements (no parentheses this time) does indeed go much beyond the so-called functional requirements even in pre-5.0 versions of Macroscope!

Now if you move to the Validation site for the next version, you'll see that we are indeed using terms such as System Requirements as you define it. I suggest we switch to the Validation site to continue this conversation.

Thanks again.
 
 
0 #7 Ed Kenworthy 2013-09-10 21:46
Serge, I feel as though I owe you and Tom an apology on two (2) accounts:
  • I have not gotten myself fully across Version 5.0, and have consequently missed some of the key and great changes that have been made (one is the New Base Delivery Deliverable Structure) which has in my view made it easier to understand Macroscope from what was presented for Version 4.8. [Some thoughts here to compile for another time].
  • The link to the Fundamentals which expands upon what was in Version 4.8 does improve the picture [… but to the average punter still hides the unique or key principles embedded within]
Two responses regarding your comments, grouped as follows:
  • Fundamentals
  • Deliverables
Fundamentals:
The 8 listed principles (having now just read them) are all great concepts, and I nearly fell off my chair when I saw the content of “PR.6 – Use a Systemic Approach” which made explicit reference to Systems Theory, holistic and the best one of all “The organisation is a business system, a system of systems” let alone PR.1 covering the whole principle of tailoring which is indeed a fundamental.

However, having read all of these, I feel the underlying Macroscope methods and artefacts that support many of these key principles are still hidden. The devil is in the detail. I feel these principles need to be drawn out in some way. As an outsider (new guy) I’ll have a think and see if I can find some way to aid this – perhaps being an outsider to Macroscope may help in this instance. I’m thinking of the Systems Engineering principles and the methods and artefacts that reside within that support it. Perhaps this is something to be posted on the Validation site.

This is possibly a bit fanciful or harsh in some ways, but I feel currently you could almost uplift these 8 principles, almost word for word, and transplant them on somebody else’s methodology and claim the same thing.

Deliver ables:
Serge, your response is perfect, excellent, and brilliant. Seriously! You have articulated exactly as I would like to approach it. It is potentially worthwhile you capturing your response under one of the principles as added detail.What you have described is how I would want to apply Macroscope, and would have (yes, I still have not had an opportunity to actually use Macroscope in anger as yet). I feel I may have become caught up in what I see happening in some areas, and the word ‘deliverable’.

I agree with your comments completely and they will assist me greatly when dealing with some current practitioners who are indeed unfortunately stuck on the “word document” template as presented within Macroscope and are unable to move away from it without feeling they are being non-compliant.

When it comes to the application of Macroscope, and perhaps some form of accreditation (I recall a proposition on this some time ago), I would strongly recommend a focus on tailoring of Macroscope to different problem sets. I would be happy to be a contributor to this if you feel I could add some value.

One thing I would change though is the following:
  • Owner (Business) Requirements
  • User (Functional) Requirements)Change this to User (System) Requirements as there are functional and non-functional requirements pertinent at this level and this ties in within the renaming that has occurred between V4.8 and V5 of the P230S User Alternatives to P230S System Alternatives and P240S User Principles to P240S System Requirements.
  • Developer (Technical) Requirements)Rather than Technical requirements I would prefer to see component requirements, or design requirements. I say that because I want people to move away from saying Functional and Technical Specifications.
When it comes to requirements, or hierarchies within a System, I tend to think in terms of:
  • Business Requirements
  • System Requirements [and then System Architecture/De sign]
  • Subsystem Requirements [and then Subsystem Architecture/De sign] if required to further breakdown a complex system
  • Component Requirements [whether software, hardware, or …] and then Component Design.
This structure, or hierarchy would reflect the product breakdown structure (or system breakdown structure).

Sincerely thank you for your response Serge.
 
 
+1 #6 Serge Deschamps 2013-09-10 14:44
Ed: in reply to your comment dated 2013-09-09 00:38.

You’ve put a lot of thought in your comment and the team greatly appreciates this spirit of collaboration. The items on your list of “basic principles being sought” are all deeply imbedded into Macroscope. The fact that you had some difficulty finding them all is very helpful information. We had tried to bring the main ones more to the forefront in 5.0, but we clearly need to do more on that topic.

Let me go on a tangent here related to your “plethora of deliverables” issue. This is a debate that has been more or less raging since probably the very first incarnations of our methodologies, dating as far back as the “Brown Guides” in the early 80’s. Why don’t we propose a single requirements “document”, one single specifications “document” instead of a “plethora of deliverables”?

Let’s remain in the paradigm of written documents for this conversation (it is sad that tons of users of Macroscope today persist in equating a deliverable to a Word document!). If one looks closely at the “Deliverable Structure” proposed in the Solution domain (V5.0), how many “deliverables” do you see? I personally see six deliverables:
• Requirements
• System Architecture
• System Specifications
• System Components
• Quality Assurance
• Organizational Change Management

In some projects, these are the only one I’d produce! And still be 100% “compliant” with Macroscope

In some other projects, depending on the context, I may need to break down, say, the Requirements into three separate deliverables:
• Owner (Business) Requirements
• User (Functional) Requirements)
• Developer (Technical) Requirements)

Why might I have to do that? Maybe because of the complexity, of the number of stakeholders, of who needs to produce, validate, approve, etc. Maybe is such a situation, producing a 50 page document would bring me nowhere, other than producing waste, as no one would be able to digest the document in its entirety.

And may be in some complex technology settings, I’d need to further break down the Developer (Technical) Requirements into two distinct deliverables because I need to evaluate and explore some alternatives that may influence the overall design of the solution:
• Developer (Technical) Alternatives
• Developer (Technical) Principles

We have another important consideration – some of these things will be highly useful for ongoing maintenance. So we need to make it easy to carry those things forward without duplicating work – and to separate them from everything that deals with just a single point in time. In my last example above, the Developer Alternatives ‘document’ will likely be archived as history while the Developer Principles will hopefully remain a living reference for maintenance and evolution work.

I think you see my point.

We may also look at deliverables as “manageable pieces of project work”, one of key Macroscope principle stated by Tom. Depending of the project’s size and complexity, some of the more specialized deliverables will be useful or not. A web-site delivery project will insist on user architecture deliverables while an “Infrastructure as a Service” initiative will rather focus on technology infrastructure architecture. It’s the project manager’s and the solution architect’s responsibility to select and adapt the process and deliverable structures to the particular project conditions.

The huge over-arching principle is that Macroscope has always been intended for people who think. If we tried to make it prescriptive for all people in all situations, we would fail badly.

But even if people are highly trained and experienced in software engineering and the other disciplines we need – we find that people still need a bit of training before they will really embrace it.
 
 
0 #5 Ed Kenworthy 2013-09-09 00:38
Tom, I could not agree with you more when it comes to “strongly promote the thought leadership that is imbedded in Macroscope.”; to that end it would be good if the fundamental principles that reside within Macroscope were more evident to the practitioner – old and new alike. Apologies if this is already present somewhere – but … it has not jumped out at me.

As a new participant in the Macroscope community I did not find it easy to understand what Macroscope was actually offering and how to adopt it. The taxonomy did not help matters, and the “V” diagram gave a false sense of hope until I looked at it in more detail. One thing that made it difficult, until I had completed a mapping, was the plethora of material representing what I consider to be one deliverable. Macroscope appeared to have spread the key contents of what I would normally see in one deliverable (such as a System/Subsyste m Requirements Specification or a System/Subsyste m Design Document) across multiple different deliverables – as though the sections of a Systems Requirements Specification had been ripped out and allocated their own template (regardless of size), or each engineering method or process you used required its own deliverable.

The only way I knew how to understand and how to apply Macroscope, and thus determine its strengths and weaknesses, was to map it to a “systems and software engineering standard” (what I consider to be a generic structure of specifications [more on this later]) and Systems Engineering principles. Once I had completed this exercise the strengths and weaknesses became more obvious to me, in particular some of the strengths which aligned with a systems engineering approach. It’s time for them to come out!

I have been meaning to post this mapping for consideration, albeit it uses the terminology of Version 4.8 and is a bit hard to follow in its current format so I am looking at a simplification (perhaps a revision to your V diagram).

The following is not a critique of Macroscope (all material here-in is based upon Macroscope © V 4.8) or how well it fits the system engineering paradigm. It only aims to point out some of its attributes that do fit, and some of the complexities it may have when it comes to specifications.

The potential to adopt a methodology to a systems approach will come down to:
  • realising what part or parts of the systems engineering paradigm it covers, what shortfalls or advantageous may exist, and thus the gaps that require coverage from elsewhere;
  • the mind of the individual doing the adoption and application; do they have the right mindset, experience, knowledge, understanding and desire;
The basic principles being sought:
  • Holistic view – life cycle costs
  • Integration of all engineering disciplines as required for the problem, solution space – integrated product teams
  • More than just software specification and design
  • Use of building blocks, end products and enabling products
  • Requirements management – requirements derivation, allocation, flow-down and traceability
  • Employ levelling of requirements definition, design, and integration
  • Trade off analysis – alternative solutions, measure each solutions effectiveness in meeting the business measures
  • Selection and tailoring - design of the delivery approach
The attributes found within Macroscope
  • A strong focus on aiming to understand the business domain/problem.
  • Encompasses full life cycle, but its complexity, or plethora of artefacts covering specifications and design, may result in people not realising its full benefits and over tailoring of key deliverables out of there project.
  • Modules, tools and methods that cover the major phases of system development, but unfortunately are not being used as extensively as they could be and thus returning the rewards and benefits they actually have to offer.
  • Supports Trade-offs – which I am not seeing as being undertaken by practitioners
  • Supports Architectures at all levels (excellent)
  • Discusses the right concepts for requirements management but was managed separately to the specifications and design documents.
Observatio ns [some related to its application]:
  • Complexity or plethora of deliverables covering specifications and design and its resultant impact on requirements and requirements specifications, requirement derivation and allocation.
  • Hardware or other products addressed but almost hidden.
  • Macroscope modules (Strategy, Architecture, Solution, etc.) being used in isolation of each other rather than holistically – comes down to the practitioner and not Macroscope.
  • Similar to other methodologies and their application, practitioners have a tendency to tailor out the benefits, resulting in a “functional specification” and “technical specification” mentality. To some degree Microscope’s plethora (to the lay-person) of deliverables assists this.
  • Not effectively being tailored to a given situation by practitioners – tends to be what “the practitioner” knows (or may not know), what they did last time, what is “always done because …”, or “… we only do small projects and don’t require all those other artefacts” without fully understanding what is being removed.This latter point is one downside of the plethora of deliverables on offer.
The way forward may be:
  • Training in the principles of systems engineering and software engineering that are embodied within Macroscope first, before going into the details of the Macroscope deliverables etc; and how those deliverables may map
  • Training in how or where Macroscope aligns to a systems engineering approach.
  • Simplify the specification tree, or provide a mapping (reference model) to enable faster take-up. I do not see the current “V” model doing this.
“Since the 1980s Macroscope (under various names) has always encouraged us to “manage by deliverables” (the language has varied). This means we first select our useful work products and then create our work breakdown structure with mostly deliverable-cen tric activities. The first version of PMI’s PMBOK made absolutely no reference to work products. Its approach to the WBS was based purely on activities. But if you look at the PMBOK today – it does indeed encourage a focus on work products before creating the WBS. “

This is interesting as this did not initially jump out at me when I first viewed Macroscope. This is what I would refer to as a System Breakdown Structure (SBS) [the products], which is then fundamental to deriving the Work Breakdown Structure (WBS) and enabling the development of a specification tree.

Acronyms on the picture:
• SE Mgt = Systems Engineering Management
• T&E = Test and Evaluation
• ILS – Integrated Logistic Support
 
 
0 #4 Davidoff 2013-07-31 08:16
I've never seen it work that way either. But as to the why .. I can frame a story grounded in my customers vocabulary - but mapping that story back to the Macroscope taxonomy has never been an easy path. More on this topic soon.
 
 
0 #3 Tom Handley 2013-07-30 12:48
Quoting Serge Deschamps:
You may get some comments on your last bullet assertion. A bit as you state in your preceding bullets, what we invented in the 90's (Results Chain technique, Benefits Realization and Value Management approaches) have been gaining popularity in recent years. For example, have a look at the Managing Benefits Community of Interest... you'll see lots of references to the APMG's practitioner certification on Managing Benefits.


Oops - I hope the readers forgive my blind spot. Benefits management is now much more mainstream than I implied in my original posting. I plead guilty to a bit of "tunnel vision". (And I note that some contributors to the MC CoI forum have Macroscope background.)
 
 
0 #2 Serge Deschamps 2013-07-30 10:28
As support to your posting, here is how the then four domains of Macroscope were presented in the Statement of Direction presented in 1992.

The Macroscope features four major components domains addressing the four critical sets of issues involved in inducing change into an organization through the application if information technology.

DMR Strategy Plus (now called Vision): identifies the business drivers for change, defines the nature of the contribution of IT to the business, formulates the strategy for change in the business, irs organization and its IT, and ensures strategic management of its implementation.

DMR Architecture Plus (now called Architecture): assesses the current architectures, develops target architectures for business processes, information, applications, and technology, evaluates delivery capability, and manages the transition program.

DMR Productivity Plus (now split and called Solution and Project): installs the change delivery environment, evolves and redesigns information and work systems, engineers the changes, and deploys technical and organizational changes throughout the organization.

DMR Benefits Plus (now called Benefits): implements the benefits management infrastructure, and ensures that the benefits from investments in information technology are fuly reaped, that delivered assets are preserved and maintained, and that new benefits opportunities are recognized.
 
 
+1 #1 Serge Deschamps 2013-07-30 09:21
You may get some comments on your last bullet assertion. A bit as you state in your preceding bullets, what we invented in the 90's (Results Chain technique, Benefits Realization and Value Management approaches) have been gaining popularity in recent years. For example, have a look at the Managing Benefits Community of Interest... you'll see lots of references to the APMG's practitioner certification on Managing Benefits.