SharePoint Saturday New England: BI and Productivity Tools for IT Project Management featuring SharePoint and SQL Server

Event:
SharePoint Saturday New England
Saturday, October 28, 2017

Session Title:
BI and Productivity Tools for IT Project Management Featuring SharePoint and SQL Server

Abstract:
IT organizations are responsible for delivering and maintaining technology solutions and capabilities for their customers and throughout their organizations. Resource constraints and business uncertainty is common and barriers often deter IT organizations from investing the time and attention necessary for measurable process improvement, resulting in a reactive approach to problem solving and execution. Now is the time to empower IT project teams with reports, dashboards, and notifications.

This presentation demonstrates how to create business intelligence and automation tools for IT project management using SharePoint Server, SQL Server Integration Services (SSIS), and SQL Server Reporting Services (SSRS). This session covers high-level concepts as well as practical, hands-on instructions based on real-life solutions.

Slides:

Presentation Slides

Chart of PMBOK(R) Fifth Edition Knowledge Areas and Process Groups

Description

This chart illustrates the Project Management Knowledge Areas and Process Groups as defined by the Project Management Institute (PMI.org) in the PMBOK(R) Guide Fifth Edition which was published in January, 2013.

(PMI, 2013)


References

Project Management Institute (January, 2013). A Guide to the Project Management Body of Knowledge (PMBOK Guide) Fifth Edition. Newtown Square, PA: Project Management Institute.

Lessons from an ERP Project Failure and Vendor Law Suit

A customer/vendor conflict: 

In a recent Computerworld article, Chris Kanaracus explains how Epicor Sued Over Alleged ERP Project Failure.  In the article, the customer attributes the project failure due to shortcomings in Epicor software.  Customer states, "The project did not go well due to a variety of shortcomings in Epicor's software."

Here is my analysis:

In my experience doing these sorts of procurements, when specific business requirements are defined well and included in the RFP, SOW, and contractual documents, then many project risks (both cost and schedule types) are shifted to the vendor. If the vendor agrees to meet a specific requirement and both customer and vendor sign the contract, then vendor is on the hook. However, if the requirement is not documented in the initial contract, then the vendor may later push back by describing the requirement as "out of scope" and will only do the work if they can bill the hours. Scope creep is not only common in ERP projects, it is actually a well-accepted fact.

As a casual reader of the article, I must state up front that I don't have all the facts in this story.  I only know what I read in the article.   So, based on the article and past experiences I can go out on a limb and suggest two things that might have happened:

1. The customer failed to specify the steps of a key process and include those details in their contract with Epicor.  Therefore, the process became ambigious and unclear.
2. Epicor team attempted to remedy a technical shortcoming through additional pro services (billable time), and they failed to reach customer satisfaction before the bill got to be a million bucks.

Lessons to be learned:

This article reminds us of some key lessons that we can use when working with vendors.

• Invest as much time as necessary into defining processes well.
• Identify specifics even if they are obvious or assumed.
• Include specific business requirements, solution requirements, use cases, story board, and other illustrations in the vendor contractual document.
• Group related requirements into "categories" and seek fixed pricing estimate for each category (this forces vendor to do more careful estimates and makes the project easier to manage).
• Create a project completion checklist up front (should map closely to the categories) and include that the contracts.
• Realize even if you defined requirements really well, you still might miss important ones.  Therefore, remember to buffer the project budget to cover requirements that may have been missed.

A fixed bid estimate may cost up to 25%-40% more than a standard estimate, but that is a significant discount over the 500%-1000% overrun that is not only possible, but likely if the requirements are not clearly spelled out and the work begins.

References

Kanaracus, C. (August, 2011). Epicor sued over alleged ERP project failure. Retrieved October 20, 2011 from http://www.computerworld.com/s/article/9219127/Epicor_sued_over_alleged_ERP_project_failure?taxonomyId=144&pageNumber=1.

General Business Requirements vs. Solution Requirements

What came first, the solution or the need? Let's hope the need, but we all know that is not always (often not) the case. With the great technologies available to us today, rapid application development enables us to solve problems. But, does the ease of development actually create a new set of problems? Yes, it does.

When the software development process is lengthy and drawn out, it forces many planning activities such as requirements analysis, design specifications, and planning. Not doing these things leads to costly adjustments later. The lengthy process also forces organizations to really think about what solutions they are developing and how these solutions fit into the big picture. We've got it pretty easy today. With portals, collaboration, search, BI, content management, and workflow platforms today, some times doing it "wrong", undoing it, and doing it again is actually less expensive than the cost of planning and documenting.

Yes, I am familiar with the twelve principles of the Agile Manifesto (Agile Alliance, 2001). I like agile development when it follows some organized processes and produces artifacts that can be used for reference later. You still need documentation for future development, disaster recovery, and repair.

However, what I don't like is "premature solutioning" or the practice of directly jumping from a problem to a solution design without any sort of further questioning, analysis, thought, or sanity checks. When you encounter a problem, and immediately form a solution and begin developing it, a lot is lost. You are not considering what other stakeholder needs are, what other colleagues are already working on, and how this "fly by the seat of your pants" solution actually fits in (or doesn't) into your overall information architecture.

Working with my colleagues, we recently began formalizing our thoughts around the solutioning process. One of the first roadblocks we encountered had to do with semantics. We began observing that our push for "requirements" was being misunderstood. When a problem-solution situation arose, we would explain that we needed to analyze requirements. The response to this typically included design specifications. We would then stop and say, no, we don't want detailed design specifications, what we want is to understand the problem better and understand how it impacts other people, so we can create a solution that will fit into our information architecture in a way that adds value and doesn't undermine anything else we are doing.

After a few more of these scenarios we decided that we had to make others aware of our solutioning process and how we think, so that everybody would be able to communicate with each other better. The first thing we did was make a distinction between the types of requirements that we would discuss in the course of solutioning.


We decided on the following:

General Business Requirements - Facts and opinions that help understand the problem better. These are not design specifications and do not explain a solution. Instead, this information explains what the business needs are.

Solution Requirements - Facts and opinions that define how a solution is supposed to look, feel, or act. This information directly dictates the design specifications.


So, now when a new request arises, we start by gathering "general business requirements." We then consult with stakeholders, policies, procedures, standards, goals, etc. and analyze the information. Once we have all the facts, we begin to design a solution. At that time, we ask stakeholders to help us define the "solution requirements." The result of the latter activity is a design specifications document. Next, we schedule and plan the development activities and proceed from there.


Reference

Agile Alliance (2001). Principles Behind the Agile Manifesto. Retrieved July 24, 2010 from http://agilemanifesto.org/principles.html.

Inconsistency in Information Management System Governance, Projects is Kryponite

I continue to revisit the thought that a SharePoint governance model (policies, procedures, standards, resources, etc.) can be undermined if an organization does not employ proper and consistent governance for all of its information management activities and systems.

Consistency is important because it level sets the way that people approach information management projects, including SharePoint projects. If some projects were to take a fly by the seat of your pants approach, disregarding governance concepts, it is bad because the resulting deliverables will be inconsistent from what the guiding principles that the governance model is supporting. What is worse is the sloppy result is the one that is achieved first, since it takes less time to do things when you circumvent processes.

Meanwhile, you might have some projects following the rules and progressing a bit slowly while the wild wild west ones are moving fast and crossing the finish line earlier. By the time the "good" project finishes, the wild wild west has already become the de facto standard. A precedent is set and now all of those "unnecessary" rules are perceived as pockets of resistance and momentum builds in avoiding the rules rather than following them. This is a vicious cycle and requires quite a lot of effort to reverse the damage. It is much easier if the executive sponsors can support the governance concepts, then promote and mandate accordingly.

The benefits of the formal approach to projects and adherence to information management governance is obvious to anybody who has experienced a complete project life cycle and then stuck around long enough to observe the after effects. This topic is very much philosophical; do you want to manage projects short-sighted to get the project completed or do you want to manage projects for the greater good, long term to support the guiding principles of the governance model?

I will draw an analogy. You live in the mountains and have a wood stove. You can spend cheap money buying an axe, then hurry to chop wood with it to meet an immediate need of filling the stove once. Or, you can invest more money on a chainsaw and then be able to provide wood for the stove, more efficiently, every time you need it moving forward. It is called return on investment. Sustainable efficiency and the ability to produce higher quality deliverables (which are easier to maintain) is the result of following a slow and steady approach to information management projects; taking the time to remain aligned with the principles of the governance plan.

Use Case Points for Project Estimating

Use Case Points is a project estimating technique that helps you to determine complexity level of use cases, human participants, non-functional requirements, and software environments (Cohn, 2005).

Due to the rapid development nature of SharePoint, I think Use Case Points may be an efficient estimating tool for large SharePoint projects which are being formally managed. Such projects typically have an upfront investment in business analysis and likely have documented outputs including use cases. Use cases can be written like a sequential script of steps and exceptions to explain various ways that the system will be used. I think use cases themselves provide a great deal of value on a portal or search project because they provide greater visibility and detail about the requirements of the solution.

So, taking an artifact (use cases) that might already exist for a SharePoint project, you can simply use this information and apply the Use Case Points technique to gain other insights about time and cost estimates for the project.


Reference

Clemmons, R. (2006). Project Estimation With Use Case Points. Retrieved February 24, 2010 from http://www.stsc.hill.af.mil/crosstalk/2006/02/0602Clemmons.pdf

Cohn, M. (2005). Estimating With Use Case Points. Retrieved February 24, 2010 from http://www.methodsandtools.com/archive/archive.php?id=25.

Koirala, S. (2004). How to Prepare Quotation Using Use Case Points. Retrieved February 24, 2010 from http://www.codeproject.com/KB/architecture/usecasepoints.aspx.

Program Evaluation and Review Technique (PERT)

Having worked in many different types and sizes of companies, I have always found there to be a great variance in how long it takes to accomplish certain tasks. For example, one organization might have lots of hardware at it's disposal, while another might need to order hardware. Or, another good one is the task of setting up DNS records. I've been in places where I can simply log into Active Directory myself and create what I need without hesitation, while other places can take upwards to a week to get a DNS record pointing to an IP address.

Whatever the case, the majority of the time it is the company's processes and resources that define how long something takes.

This week, I've been using the Program Evaluation and Review Technique (PERT) to estimate the duration of an extranet portal project. Fortunately, I have a very good sense for the company's processes so I can factor these things in fairly accurately. Still, I really like to include PERT calcualtions in my project plan because it allows me to factor in optimism and pessimism and come up with an accurate duration.

With PERT you calculate a weighted average by doing this:
Optimistic Time + (4 * Most Likely Time) + Pessimistic Time / 6 (Schwalbe, 2009)

So, if I wanted to estimate the time it takes to spin up some virtual machines and configure a SharePoint 2010 Farm completely from scratch, I might do something like this:

3 workdays + (4 * 5 workdays) + 10 wordays / 6
Result = 7.5 workdays


Reference

Schwalbe, K. (2009). Information Technology Project Management (6th Edition). Boston: Course Technology.

Software Solution Project Planning

I like to use the following six project phases when creating an software solution project plan. I always start with these phases at the top level, then indent detailed tasks and subtasks beneath each respective phase.

Discovery
Assessment
Design
Construction
Validation
Rollout

These project phases can be applied to projects small and large. It works for new projects or add-ons to existing projects. One pattern that occurs is that the series of phases will cylce. For example, perhaps you implemented a line of business web application. Over the course of time, the requirements change and enhancements are requested. You are naturally led back into the discovery phase where you begin the cycle again. You define what enhancements are needed, you design a solution, you build it, test it, and roll it out.

SharePoint V3 brings makes project charting more realistic for small projects. Previously, creating a project plan could take as long as a small project. However, with the project-lite features and a little bit of templating on your part to reuse previous efforts, its quick to set up the plan and execute. Doing this can help you and anybody else who has an interest in what you are doing.