Throughout my career, I’ve had many opportunities to do a lot of different types of work, but the majority of my experience is in technical security and project management. In fact, I’ve carried my Project Management Professional (PMP) certification for longer than any other certification and I use those skills almost every day.
One particular area of project management that is close to my heart is defining the scope of work. I have written hundreds of scope documents, whether as part of a formal methodology or, when I was in consulting, in the form of a statement of work. I chose this time of year to write this because most companies start their new capital projects in January, so this is an opportunity to start these projects with a solid scope foundation.
Why Is a Scope Document Necessary for Security Projects?
None of us enter into a project expecting to get into arguments about the scope. We don’t ever want to be at odds with our colleagues, discussing like litigators what our teams should be doing. If we get to that point, no one wins the battle — but, unfortunately, it happens. And in my past experience, it happens on a lot of projects. This is especially true for long-duration security projects, affecting many systems and requiring many months (or years) to complete. While I could go on a rant about how far-reaching networking projects are, how long identity and access management (IAM) projects typically take, or how complex and distributed the work of building a security operations and incident management solution is, I won’t. It’s sufficient to say that it happens a lot.
One of ..
Support the originator by clicking the read the rest link below.
