Quantcast
Channel: Project Epistemology » Security
Viewing all articles
Browse latest Browse all 28

Creating a Secure Enterprise Project Type

$
0
0

Here’s an interesting question that popped up recently…how does one secure a specific Enterprise Project Type within Project Server 2010 so that only specific people may be able to create it?

Process Overview

Let’s start off by reviewing the specific business scenario.  We have an organization that has small, medium, and large projects.  Each of those projects is mapped to various initiation processes and has been assigned a specific enterprise project type (EPT).

image

All large projects must go through an executive approval process, which for now is a manual application.  The application process happens through the use of a form, which then gets signed by the relevant executives.  Once the appropriate signatures have been received, the PMO administrative assistant creates the project record based on the form.

The other path is that users may create a Medium project, then apply to get that project promoted to a Large project.  The application process is the same as defined above, and once the approvals are in place, the PMO administrative assistant will promote the Medium project to a Large project using the Change Workflow button on the Project Center ribbon.

The challenge was that the users were getting confused and would go ahead and create a Large project – even when the approval hadn’t yet been completed.  We initially attempted to train this behavior away, but found a need for more effective enforcement mechanisms.

Honestly, my first thought was to implement some sort of workflow on the backend to ensure that only authorized users would create the restricted project type.  Of course, that would imply that I would have to actually get up and talk to a developer….something I try to avoid at all costs.  (Besides, that’s what the TFS Integration Pack is for, so I never again have to actually talk to a developer.)  Smile  Then, I realized there’s a pretty simple no code solution.

Modifying the Resource Department Field

Enter the workaround.  First off, we need to look at the Resource Department field.  By default, this is a single-select field, i.e. only one value may be entered.  If you’re not really using this field, great.  Leave it as it is and continue following the instructions below.

image

If you are using this field, then you may wish to consider changing it to a multivalue field.  Before you do that though, a couple caveats….

  1. Changing a field from single value to multivalue is irreversible.  You may not change it back.
  2. Changing a field to multivalue makes it much harder to bring into the Office Data Connection files you may be using to support your BI reporting.  Review the SDK for guidance on incorporating multivalue fields in the ODC queries.
  3. Changing a field to multivalue may potentially break your OLAP cubes.  See this post from Brian Smith for a nice synopsis.  That being said, in my preliminary testing, new cubes built after the field change seemed to work just fine.
  4. Even if you don’t break your cube, adding resources to multiple departments may cause odd numbers to appear in your enterprise OLAP cubes, i.e. a resource in “HR” will show in a different department than a resource flagged to “HR, Admin.”  Of course in this case, we’ll simply change the values for our administrative assistants or PMO members – who may not be under the same scrutiny for remaining capacity as a more technical resource.

That being said, if you have already changed the field to a multivalue, then ignore all of those caveats, and feel free to continue.

The next step is to add a new department to the Department lookup table referenced by the Resource Departments field.  I will call this new department “PMO Administration.”

image

Mapping the EPT and Resources

Map the Large project EPT to the PMO Administration department.

image

One more step remaining.  Pick the individuals who will be allowed to create the Large projects and add them to the PMO Administration department.  In this case, I’ll use Niraj Shah as an example.  I modify his record to include the right department.

image

Reviewing the Results

Now let’s test it out.  I navigate to the Project Center and select the option to create a new project.  I don’t see the option to create a Large project. (Good)

image

I try to change the project type by selecting a project, then clicking on the Change button on the ribbon.  Again, there is no option to promote a project to a Large project. (Good)

image

Now, I log in as Niraj’s delegate to see what his experience would be like.  In Project Center, I now have the option to create a new Large project. (Good)

image

…and in the Change Workflow dialog box, I have the option of promoting a Medium project to a Large project. (Good)

image

There are probably still ways to get around this obstacle, but overall, it’s an easy and elegant method to make it harder for users to accidentally stumble upon process exceptions.


Filed under: Admin, Security Tagged: Enterprise Project Types, EPT

Viewing all articles
Browse latest Browse all 28

Trending Articles