Microsoft

MSF Solutions Framework Executive Overview

This project is from 2005 but I thought I’d include it because I thought it could be relevant because it offered standardization for external vendors who wanted to propose solution partnerships with Microsoft. The library offered templates, documentation, and a framework for those vendors to use in their proposals. It also gave Microsoft an easier way to look at proposals, using standard materials and information supplied by those vendors, and were then more able to compare and make decisions on which vendors they would partner with.

It was developed as an online help system using RoboHelp. I was considered a RoboHelp expert and was picked for the project for that reason. Unfortunately, the project is too old for me to reconstitute it so I had to just take screenshots to give you an idea of how it worked. There are no live links in it.

The Microsoft Services Delivery Methodology Library

The Microsoft Services Delivery Methodology Library (SDM Library) is the foundation of a Services-focused project and engagement method of guidance for delivering solutions. It builds and expands upon the already successful concepts and principles introduced by Microsoft Solutions Framework (MSF).

The organization of the methodology is such that the Engagement Management phases (outer ring of the diagram) must always be executed; but within the Engagement Performance phase, only the project phases applicable to the customer’s Scope of Work are selected and used for that engagement.

The SDM Library is an online help system that was built in 2005 by a distributed team led by a PM out of Chicago, a SME in Germany, a technical writer in Seattle, and myself, working from San Diego. I did some technical writing and built the project in RoboHelp. I’ve taken screenshots of some of the relevant pages to give you an idea of what this library offered.

Consistency and Reduction to Solution Delivery Time

The biggest draw for creating this tool was so that processes could be repeatable, everyone used the same templates, and work could be more easily evaluated because it was submitted using the same forms.

The SDM Library offers guidance in three of our main business areas: infrastructure, application development, and project management. The process consists of three main pillars:

  • Process guidance – Overall process roadmap. Step-by-step processes, lists, and flow diagrams of activities and deliverables by role, along with detailed process guidance. Assistance on how to adapt to projects of varying size and complexity is included. Using these processes allows both you and the client to always know where you are in the process.  This cuts down on the number of surprises that can occur by providing an up-to-date picture of where the engagement/project is, where it has been, and where it is heading.
  • Template guidance – The SDM Library includes a collection of templates for every delivery specified along with detailed guidance on how to use the template and what information needs to be considered or captured. Some of the templates correspond to activities that are executed internally during the project, others are for client deliverables.
  • Intellectual Capital Links – Contains links to existing intellectual capital (IC) that has been harvested in the Intellectual Capital Exchange (ICE) and that relates specifically to the deliverables specified.

Process Guidance

Intellectual Capital Links and Templates

Windows 3.1 API

I was approached by Microsoft (in a manner similar to how I was approached by Derek) to initially work on this project first as an editor and then as a writer. I had been a software developer prior to this role, but documented and trained users on my software after I installed it. I didn’t realize before then that technical writing was its own field.

I don’t have samples of the work that I did specifically, but the type of documentation I did at that time can be found at on Microsoft’s Windows Developer site. Click here to see samples of the type of documentation I did. See below for a function that was valid for Windows 3.1.

I included this to demonstrate the type of work I’m capable of doing even though I don’t currently do API documentation work.

SetWindowPos function (winuser.h)

  • 5 minutes to read

Changes the size, position, and Z order of a child, pop-up, or top-level window. These windows are ordered according to their appearance on the screen. The topmost window receives the highest rank and is the first window in the Z order.

Syntax

C++Copy

BOOL SetWindowPos(
  HWND hWnd,
  HWND hWndInsertAfter,
  int  X,
  int  Y,
  int  cx,
  int  cy,
  UINT uFlags
);

Parameters

hWnd

Type: HWND

A handle to the window.

hWndInsertAfter

Type: HWND

A handle to the window to precede the positioned window in the Z order. This parameter must be a window handle or one of the following values.

For more information about how this parameter is used, see the following Remarks section.

X

Type: int

The new position of the left side of the window, in client coordinates.

Y

Type: int

The new position of the top of the window, in client coordinates.

cx

Type: int

The new width of the window, in pixels.

cy

Type: int

The new height of the window, in pixels.

uFlags

Type: UINT

The window sizing and positioning flags. This parameter can be a combination of the following values.

Return value

Type: BOOL

If the function succeeds, the return value is nonzero.

If the function fails, the return value is zero. To get extended error information, call GetLastError.

Remarks

If you have changed certain window data using SetWindowLong, you must call SetWindowPos for the changes to take effect. Use the following combination for uFlags: SWP_NOMOVE | SWP_NOSIZE | SWP_NOZORDER | SWP_FRAMECHANGED.

A window can be made a topmost window either by setting the hWndInsertAfter parameter to HWND_TOPMOST and ensuring that the SWP_NOZORDER flag is not set, or by setting a window’s position in the Z order so that it is above any existing topmost windows. When a non-topmost window is made topmost, its owned windows are also made topmost. Its owners, however, are not changed.

If neither the SWP_NOACTIVATE nor SWP_NOZORDER flag is specified (that is, when the application requests that a window be simultaneously activated and its position in the Z order changed), the value specified in hWndInsertAfter is used only in the following circumstances.

  • Neither the HWND_TOPMOST nor HWND_NOTOPMOST flag is specified in hWndInsertAfter.
  • The window identified by hWnd is not the active window.

An application cannot activate an inactive window without also bringing it to the top of the Z order. Applications can change an activated window’s position in the Z order without restrictions, or it can activate a window and then move it to the top of the topmost or non-topmost windows.

If a topmost window is repositioned to the bottom (HWND_BOTTOM) of the Z order or after any non-topmost window, it is no longer topmost. When a topmost window is made non-topmost, its owners and its owned windows are also made non-topmost windows.

A non-topmost window can own a topmost window, but the reverse cannot occur. Any window (for example, a dialog box) owned by a topmost window is itself made a topmost window, to ensure that all owned windows stay above their owner.

If an application is not in the foreground, and should be in the foreground, it must call the SetForegroundWindow function.

To use SetWindowPos to bring a window to the top, the process that owns the window must have SetForegroundWindow permission.

Examples

For an example, see Initializing a Dialog Box.

See also

Conceptual

MoveWindow

Reference

SetActiveWindow

SetForegroundWindow

Windows