Tag Archive for HR

Using Stage-Gate Processes for More Effective Collaborative Work

Stage-Gate processes have been around for many years. They grew up to serve the needs of Product Development.  Over the last few years, we’ve seen a significant increase in the number of customers opting to use this type of design for their applications across many other functions (vs. role-based application design and classic workflow).  The main driver of this new adoption is that organizations are finding this type of design to be more effective for purposeful, collaborative work.  It lends itself to bringing a group of people together to collectively drive the results of the process.  In this article, I’ll look at the overall design of a Stage-Gate process, provide examples of different uses, and talk about how it drives effectiveness for collaborative work processes.

Stage-Gate Process Design

It starts with people aligning on the high-level Stages an item will go through.  Each Stage is then represented visually to make it easy for the group to see where things stand.  Within each Stage there are a set of activities, which must be completed for an item to pass through the Gate and progress to the next Stage.  This is really the power of this design in that the activity is separated from the top-level Stage flow.  The activities can change, but it doesn’t affect the Stages or the Gate.

Below is a screenshot of a standard CorasWorks-based Stage-Gate application.  It is used to manage an IDIQ (Indefinite Delivery – Indefinite Quantity) contract, which is a business development vehicle most often used by Federal Contractors.  The Contractor gets a contract.  The government then issues Task Orders, each of which is bid on by a number of contractors.  Each Task Order goes through a set of Stages along its life-cycle.  Decisions are made and work happens to drive the Task Orders forward.


IDIQ Program - New Task Order - ITES - annotated


Above we are showing the New Task Order stage.  The Task Orders come in here and are reviewed and prepped.  When ready, they are pushed to the Bid Assessment stage where the team decides whether to bid on the Task Order.  The key elements of the design are:

A. Stages – lay out your stages as you want them

B. Stage Management Display – where you see the items in that Stage and can access information, report, slice, dice, and take action

C. Actions/Activities – custom set of actions to be used in the Stage to get the work done that needs to be done


An important part of the design is considering what is actually moving through the Stages.  It is common to think of each item above as a record of information (list/database).  However, with CorasWorks you can associate related information and sites that act like folders.  For instance, in the example above when a new Task Order is entered, a related Task Order collaboration site is automatically provisioned.  This site is where the detail information is and the detail collaboration happens.  In other scenarios, it might be a project site.  Or, an item might just have related information from within SharePoint or external data sources which is surfaced as a virtual workspace.  The upshot is that you have a simple top-level process to track the flow through the stages, but you have access to a very deep set of supporting information and activity for each item.


Examples of Stage-Gate Processes

Now let’s look at examples of different types of stage-gate processes and how they might differ.


R&D Innovation Process for Consumer Products

This is a classic application.  One customer is using this design to manage the full-life cycle for molecules it creates to be used for fragrances and flavors in consumer products.  The molecules are created in a lab and go into the process.  They go through a multi-phase process with many detailed activities (more than 50 activities are individually tracked).  The process takes about 3 years and they have about 700 molecules at a time.


e-Policy Management for HR

One customer uses this design for their corporate policies.  They have converted more than 600 corporate policies from documents into living, digital articles.  Each policy is submitted, reviewed, and published through a series of Stages involving Finance, Legal, Admin personnel, and more.  Users are empowered to ask questions, rate the articles and make comments that can be used for revisions.


Demand Management: New Project Initiation for Everyone

This is a common use of stage-gate.  The objective is to have a visible, collaborative review process BEFORE projects are initiated.  It is part of the evolving approach for Demand Management.  We have a standard solution for this where projects are proposed and then put through the stages leading to an approved process.  When approved, this information is used to kick off the actual project management site (a downstream activity).


Application Development for IT

A stage-gate process is great for application development.  You have your basic stages of the application development process that can span the full life cycle from proposal to completion or that might just cover the development process itself (because you are using the New Project Initiation process above as an upstream activity-right!).  When the project is approved you can have a project management/collaboration site that is used to manage the development work and the related information.  This site is effectively what is going through the stages.


Proposal Development for Business Development

Many BD organizations, particularly our Federal Contractor customers, use a standardized Stage-Gate process (originated by a company named Shipley) to manage business development.   This is very high level.  In addition, each Proposal they are working on has its own Stage-Gate process using a standardized system for color reviews.  Thus, in this scenario, you have a system with two-levels of Stage-Gates.  The top level is the overall BD process with each “opportunity” being managed.  Then, each opportunity that has made it to the Proposal Development stage has a collaborative site for the actual proposal work.


Effectiveness for Collaborative Work

The power of the Stage-Gate design is that it gets a group of people on the same page of where things stand and what needs to happen to achieve desired results.  It is simple to understand and easy to use.  The key is that the people involved will be aligned on the top stages.  From there, the systems empowers all of the people involved to work together collaboratively to achieve the result.

CorasWorks has built in a number of features over the years that enable effective solutions for stage-gating.  They enable the core solution and the ability to flexibly support the many different types of activities and changes to activities to support the process.  In addition, with CorasWorks on SharePoint you have the ability to engage “external” people in the process for upstream, downstream and supporting activities.  Ultimately, the effectiveness of a stage-gate process comes by having the visibility, input and the work coming from different people, but, aligned on the core objective of your process.

Customer Examples of Work Request Management apps for SharePoint

Over the last month, I’ve worked with a number of customers that are deploying applications for various scenarios of work request management.  This category of application is very common for all organizations and works great with CorasWorks on SharePoint.  It leverages the collaborative nature of a SharePoint environment and the work management feature set of CorasWorks.  The key design principal is to recognize that they are fundamentally cross-functional processes.  In this article, I’ll look at 4 different customer scenarios.  I’ll talk about what is common amongst them and how they differ.  I believe that any SharePoint Service Delivery Management team should make this category of app a staple of their offerings.  Once you get the core design pattern, you’ll find lots of applications for it.

Basic Work Request Management app

There are six core elements that are common to work request apps as follows:

  • They are an app, meaning there is a core site dedicated to this purpose vs. it being a feature added to a team site.
  • A requestor fills in a form to kick off a request.
  • The requestor can see, track, and engage with assigned “workers” on their requests.
  • Workers and Managers do various things (automated CorasWorks actions and forms) to respond to and complete the request.
  • Requestors and others are notified of activities and/or collaborated with.
  • You have reporting on the activity.

Customers Scenarios

Here are the 4 customer scenarios:.

Materials Storage for Pharmaceutical Manufacturing

This application is for requests to store chemicals (materials) within a manufacturing group.  People make their requests and others work the requests noting how long items are stored and where. Requestors are notified of the work and they get pinged when their storage expiration date is approaching.

IT Requests for SharePoint Work and Help Desk Tickets for Health Agency

This customer uses a couple of different WRM apps for IT to support the organization.  One allows users to log the requests for the SharePoint team for new sites, changes to sites, or new apps.  The SharePoint team then manages these requests.  The other is a WRM-based “Help Desk” app where users enter tickets and Help Desk folks work them.

Employee Requests of HR for Pharmaceutical

This customer is using WRM to enable employee across the enterprise to make requests of HR.  In this case, they created three request workstreams.  Each has a slightly different set of work management activities.  From the user perspective they are able to see the different requests in a single display from wherever they work.

HR Staffing Requests for Federal Contractor

An important process for many Federal Contractors is making requests of HR to find or recruit people to work on contracts.  In this case, a business development (BD) person working on a new proposal/task order makes requests of HR to staff specific positions.  The requests are related to specific Proposals/Task Orders.  However, HR manages all of the requests centrally.


All of the above follow the same basic design as described above.  People make requests.  People work on the requests.  There is back and forth.  The requests are closed out.  There is reporting.

The interesting part is that these are four very different “applications”.  In many organizations, they would presume that they would be looking to go out and buy or build completely different applications.  However, with CorasWorks on SharePoint each of these uses the same basic framework.  Thus, armed with one basic design you can now fill many different needs and save lots of time an money in the process.

Further, when you build them, the things that you will primarily change are also common:

  • The core data (fields) of the “work request” list are different.
  • The request form is different.
  • The worker roles are specific to the process.
  • The app navigation is different.
  • The displays and most importantly the worker/manager actions, work forms, and notifications are different.
  • Reports are different.

With CorasWorks, each of the above is easily modified using our wizards.  So, you have a common app design and you know the common things that you will be changing to accommodate the specific needs of the app.  If you look at it like an assembly line, you are all set to deliver.

Key Deployment Differences of the Apps

While the four apps have many core commonalities, there are differences in the overall deployment approach across the SharePoint environment.  This is important because work request management is fundamentally a cross-functional collaborative process.  Thus, where people go to engage, whether requestor, worker, or manager, can be different based upon the scenario.


In the Materials Storage app, all of the different users work in a single app site.  Requestors go there to make their requests.  Workers go there to do their work.  Managers go there to manage.  This makes it easier to create the app and is the way you would typically start.  However, it is not really a best practice given the ability to distribute functionality using CorasWorks.


In the IT Request app, the Requestors don’t go into the app app site to make requests.  They are able to be elsewhere across the SharePoint environment and enter their requests from their and see their requests and interact.  This makes it more convenient for the users.  Generally, you start by building the app as an All-in-one and then just distribute the displays.

Many Projects to Work Management Team (Hub and Spoke)

The HR Staffing app is a bit different.  In this specific scenario, you have many Proposal/Task Order sites (or could be project sites).  A team is working on these projects.  They enter their requests from the site.  However, the HR Work Request site is central – all of the requests feed into the one app.  HR is then able to manage it all in one place and interact with the requestors via their project sites.  This ends up as a Hub and Spoke deployment.


The Employee request design is different also.  In this case, there is a self-service page in the enterprise portal.  Users go to this one place and enter and see their requests across the three types.  The requests are funneled into the three different workstreams managed by HR.  HR is also able to work on them via a single display.

Getting You Spun Up for Work Request Management

The work request management category of app is a staple of SharePoint environments that have gone past basic site centric content sharing.  We often work with customers to train up their SDM teams to deliver this category of app.  We have a standard set of templatized apps and training to help get you going quickly.  Email support@corasworks.net for more information.