Project Management

Please login or join to subscribe to this thread

Adding Solution approach in SOW

linkedin twitter facebook  
avatar
Anonymous
Hi,
I have been asked to put project architecture diagram and solutioning in SOW. I know we add architecture and solutioning in Proposal as that is what we are proposing to client. My concern is if we add architecture and Solution approach in SOW, we can get bind to use the same architecture and solution during project execution. Is there any risk to add that in SOW?
Sort By:
avatar
Khai Ng. IT PMO | IT Project Manager| TTGROUP Hanoi, Viet Nam
There will be very risky to your team if you just add architecture diagram and solution approach to SOW document just to polish your proposal without commitment to provide them. SOW document, when approved, is a baseline document that will be used by your client to compare what you deliver with what have been aggreed upon. You should follow change management process to have your changes to architecture and solution formally accepted and make changes to SOW document before you actually implement them.
avatar
Keith Novak Tukwila, Wa, United States
Do you mean Scope of Work, or Statement of Work?

Scope of Work is part of a system architecture as it helps define the purpose of the system. A system network diagram is part of the system "logical architecture" (how the product works).

The high level WBS which is the basis of a Statement of Work is also part of a system architecture as it shows how the scope is broken down into work packages.

I would question which type of documentation you include those artifacts in, but both the systems engineering definition (architecture), and the detailed statement of work should be under configuration control as Nguyen points out. The risk is that if you make high level changes that affect the system architecture, the architecture defines all of what must be done so it may impact significant portions of the WBS and other formal planning documents.
...
1 reply by Pawankumar Gupta
Feb 18, 2021 6:44 AM
Pawankumar Gupta
...
It's Statement of Work.. Sorry for the confusion
avatar
Pawankumar Gupta Pune, Maharashtra, India
Feb 17, 2021 11:01 AM
Replying to Keith Novak
...
Do you mean Scope of Work, or Statement of Work?

Scope of Work is part of a system architecture as it helps define the purpose of the system. A system network diagram is part of the system "logical architecture" (how the product works).

The high level WBS which is the basis of a Statement of Work is also part of a system architecture as it shows how the scope is broken down into work packages.

I would question which type of documentation you include those artifacts in, but both the systems engineering definition (architecture), and the detailed statement of work should be under configuration control as Nguyen points out. The risk is that if you make high level changes that affect the system architecture, the architecture defines all of what must be done so it may impact significant portions of the WBS and other formal planning documents.
It's Statement of Work.. Sorry for the confusion
avatar
Keith Novak Tukwila, Wa, United States
The solution approach could go in the SOW, but I wouldn't consider that the right place for an architecture diagram.

Someone has the responsibility to manage the solution approach and so the work required to do that goes into the WBS. Often that is me personally, and whether my title is a PM, or some technical function like Integration Engineer, I have work to do like managing product iterations, design reviews, and closure activities. Based on the level of effort required for that discrete SOW, I may do all the work myself, or we may need to hire additional people to support.

The architecture diagram doesn't really belong there however. It is more of a technical artifact than a description of work. For smaller, less complex projects I can certainly see how it would work, including change incorporation. For larger projects, specific types of information get segregated for effective management. Product definition documents are segregated from process documents, in part due to their lifecycles.

An example of why this may be important is the risks associated with duplicate product definition data. The architecture diagram likely has another location where it is kept in addition to the SOW. If the version in the SOW is not kept up to date with the authoritative version elsewhere, it is easy for different people to be working to different product definitions, and then errors happen.

Please login or join to reply

Content ID:
ADVERTISEMENTS

"A pessimist sees the difficulty in every opportunity; an optimist sees the opportunity in every difficulty."

- Winston Churchill

ADVERTISEMENT

Sponsors







Vendor Events

See all Vendor Events

Newsletters

Jun 3: The Career Problem Facing New PMs
May 20: Your PM Career as a Project Life Cycle
May 13: The Big Lie After Layoffs

See all newsletters