Project Management Standard

Scope:

Is there a definition of what “significant” means in the context of how this standard applies?

“Examples of projects includes in the scope of this standards are”

should read:

“Examples of projects included in the scope of this standard are”

“Assess Risk Asses” should read “Assess Risk Assess”

Are the numeric rankings a required part of the project documentation?

Many of the projects we work on have an IT component, but are not primarily IT driven. i.e. an academic initiative may require certain IT support, but the larger context of the project includes training and pedagogy support, curriculum design, reporting and compliance, student service planning, etc. Where do those sorts of projects fall as it relates to this standard?

“At a high level, this plan identifies milestones; at a detailed level, it is a complete work break down structure.”

A complete work break down structure may not be possible for projects with iterative development cycles, extended development timelines, complex dependencies, many unknowns, etc.

How is this standard applied to projects with iterative development cycles?

As an aspirational document, this standard is pretty good. However, achieving that level of documentation and process definition within IT and other parts of the university seems like it would require more project management resources than the university currently has, unless this is applied with a very limited scope. Is it useful to have a standard that only addresses very large projects and does not provide guidance on small to medium ones? If this standard is to be applied more broadly, how will UNM address the cases where a project is needed, but project planning and oversight resources are limited? Cancel the project? Obtain project management support from a central entity? Obtain funding to supplement departmental project management resources?

On the artifact side, the document seems heavy on paper artifacts and formal reports. There are many electronic project management tools available (Jira, Redmine, Basecamp, Trello/Slack…) How would departments prove adherence to the standard for artifacts using these tools?

I currently am the only IT project manager in my department, with over 200 projects that I track. Some of these projects are entirely IT driven, some have at least one IT component to them. As UNM IT well knows, staffing is limited. There is no way we can keep up with all of the paperwork and documents this standard requires. I know that this standard is a ‘guideline’, but it is a ‘guideline’ with a compliance section.

I was once a programmer at IT and can’t think of a single project that I worked on that had EVERY document and the sheer amount of information mentioned here.

In my opinion, the ‘evaluate the project’ rubric is a best guess tool, and at the University, priorities can change overnight.

To echo Elisha’s comment: what does the word ‘significant’ mean in terms of Scope of the Standard?

The standard says it will provide ‘guidelines’ and the forms are ‘tools’. The methods each department uses to gather this information the standard implies, is their own choice. So we can use scrum, Agile, etc. However, the information that is needed by the standard falls under the waterfall project management method. Under the Compliance section, it states that departments are subject to Internal Audits. So, if I use agile, then that means I am forced to also use waterfall also in order to comply with the standard. Now that is a lot of work for a single project manager.

Yes, there are no templates or forms specified, but judging from all the information that comes under the standard, I’m pretty much forced into those forms.

This standard is implying I have to follow it for every project, huge or small, sensitive data or not. What if I can’t keep up with all the paperwork and forms? The projects won’t stop. UNM IT certainly knows this. What happens to the projects that must have all of this paperwork figured out before executing the project? I cannot oversee all of these projects to the degree and detail called for in this standard. What then?

Project Management tools should be applied commensurate with the complexity, importance, and cost of the project. The development and deployment of a standard is an important first step in the lifecycle of continuous process improvement.

There are a wide variety of tools, sample templates, and Sharepoint sites available from Main IT that can serve as examples. This standard will continue to evolve and course corrections will be applied as they are discovered and vetted. While the standard does relate most closely to the waterfall SDL, it can be applied successfully using agile methodology. Indeed, within IT there are several big projects using the PM standard and agile methodology. The two are not mutually exclusive and the standard is flexible enough to cover any model.

One of the primary benefits of the PM standard is to begin to raise awareness of best known practices as they relate to project management, and to continue to nurture the quality journey here at UNM. Sound project management is not about checking boxes or filling out reams of documents. It is about applying sound PM principles to projects commensurate with the demands of the project to help shepherd the project to a successful end (agnostic to methodology).

The standard represents a compilation of “best known methods” (BKMs) and globally accepted project management practices. The UNM PMO will be glad to assist you with answering any questions you may have in applying the standard as well as supplying proven templates and sample documents (tools). We understand that there is more work that needs to be done to sharpen the standard and to make it more suitable to cover the wide spectrum of projects here at UNM.