Activity, Request, Project Management - why separate?
An Activity, a Request and Project walk into a bar.


Sometimes I wish I were an academic.  It must be awesome to sit around and theorize about how the perfect world operates.  I could write books about Nirvana (not the band) and listen to Nirvana (the band)…But let’s GET REAL, I’m @VigilantGuy and vigilance requires actionable improvements today.


I have great respect for many in the ITSM industry, but sometimes we get a little too carried away.  We make things more complicated than they need to be, and we fail to deliver some practical useful take aways. (I’m guilty of that as well)

Stephen Mann (@Stephenmann), analyst, industry insider, and active giver to the ITSM community is one I respect a lot.  I have a book mark to Mr. Mann’s blog ( and I reflect on it quite often.  Simply for one reason:  Are we there yet?


Stephen challenges IT professionals in this blog to think beyond being a Service Broker, beyond the walls of IT requests.  I love him for that, but we are just not there yet.


So I challenge you with something more pragmatic and a little bit more; fix it today.
Project Management
Your Project Management is atrocious… you know I’m right.
You take 5-10 meetings to determine the project scope, the approval of the project and defining the charter.
You create 20-40 page documents about business justifications, that speak in terms 3 people in your IT organization understand.

You then proceeded to plan out a cadence of project reviews, project status, resource planning, work assignments…


STOP right there.  What is the outcome of all this time & money?
Requests, approvals and change releases.
     Requests for new hardware, approval of hardware, release of hardware.
     Requests for new software, approval of software, release of hardware.
     Request for development changes, approvals, releases.
     Request for removal of software, approvals, decommission.
     Request for removal of hardware, approvals, decommission.

     Requests, configuration changes, asset management, resource management…  sounding familiar.


This is a total FAIL.  You are trying to orchestrate a department, systems, and disciplines around “Activities” you are calling Project Management.  Well isn’t that what your Service Management initiative is supposed to do?  Why are you looking at PPM (Project & Portfolio Management) & ITSM as two different things?
WOW! Matt are you saying Project Management as a separate and distinct function is waste of time and money, and that an improved Service Management strategy where projects are embedded into the Service Portfolio would be easier for IT to act on as part of their daily operation?
No, but I should, cause that is a freaking awesome question.
In my last blog on Knowledge Management, I showed a workflow from project ideation to operation.  Embedded in that was project management layered into service management governance.  (Ahh – sneaky I was).
IT Service Management is about “How work gets done in IT”.   It’s about how the activities of IT are orchestrated and conducted to improve and meet corporate objectives.
What most ITSM consultants call IT Services are useless focuses.   Many times they are not even Services, they are Systems and Activities.  (Email – System; Backup – Activity)
Project Management has fallen into that same trap.  Most projects are just “Major Requests”.  An order of magnitude that requires some sponsorship and prioritization.  Ultimately this “Major Request” transitions into tens or hundreds of regular requests.
OK, so where is the pragmatic “help me today tip”.
Take your GANT chart and SHOVE IT… into your request system.
– Add to your Request Types:   Portfolio
– Add to your Request Items: Project Name
– Look at your activities.  They are all requests, take them and put them into your request queue, with the appropriate dates.
– Set your assignee the resource who owns it.
– Utilize the request queue as a method of activity ownership and assignment, as it was built to do.
– Leverage the Request Type & Item as filter for your reporting
Now step back and look what challenges this solved for you:
Resource Conflict between Break Fix – New Projects: SOLVED you can see assignees that are over booked.
Lack of Awareness from Operational Team about Project activities and changes: SOLVED they are in the queues and visible
Lack of Knowledge created about artifact introduced through Projects: SOLVED request notes are already part of Knowledge Management (they better be, or you need forget projects and get back to basics)
Project status, tracking and readiness: SOLVED request management workflow handles this

Even if you don’t do Agile methodologies, you can see how streamlining the digital information and relationships can optimize the output of your team.  This will help reduce waste, improve transparency, facilitate communication, and drive organizational agility.


BREAK DOWN THE WALLS & UNLEASH IT CAPABILITIES… ok, may have gotten carried away there.


So this brings up some interesting issues:
Our development and testing teams don’t use request management.
Our project portfolio handles costs, earned value, time tracking.
Our Service Management teams are separate from our PMO.


In my next blog I’ll tackle these issues by covering Digital Transformation the imperative for IT
Written by

Digital Transformentalist Twitter: @VigilantGuy Linkedin: Web: Matt Hooper is an industry advocate for Service Management strategies and best practices around Enterprise Service Management. For over 20 years Matt has instituted methodologies for business intelligence and optimization. Leveraging technology to drive business outcomes, he has built an industry reputation for his highly effective approach to creating value through Service Management. Matt is active on Social Media known as VigilantGuy, and co-hosts the weekly podcast: Hacking Business Technology.

Leave a Reply

Matthew Hooper

Digital Transformentalist