See this link for more details: http://blogs.office.com/2014/07/21/microsofts-unified-technology-event-for-enterprises/
As has long been predicted, this will be the big one – where the worlds of collaboration collide for a unified Project/SharePoint/Exchange/Lync conference.
In my training sessions, I often use sports metaphors for project schedule modeling – this, despite my utter lack of any sort of athletic ability and pathological indifference to most sporting events. The thing is, sports events are great examples of predictive models.
Take the World Cup for instance. If I were to ask you who would have taken the Cup way back at the beginning of this thing, you would have selected from 32 teams. At a basic level, we could say that each team has an equal chance of winning. Of course, we can make the model more complex. We can look at individual player performance, historical records, playing style, locations in which matches will be played….. When we throw all of those together, we can create a model of the top 5-10 favored teams.
What is this doing? It’s adding information to the model to predict the future – and providing a range of potential outcomes. Like any schedule, as I learn additional information, I include that in my model and refactor the results. From where I sit at the time of writing, we have now gotten down to the quarterfinals. Of the 32 teams that started, 8 are left. Clearly, I can remove 24 of the original candidates from the list of potential winners.
Simply by removing those 24 from the list, I have greatly increased my chances of being correct about who will win the championship. Can I tell exactly who will win? No, but I can apply my data modeling structure to the remaining teams and come up with a much better prediction than when the games started.
Extrapolate that forward, and as each game is played, the potential outcomes for the competition narrow even further. Eventually, we’re left with two teams – which greatly simplifies the modeling. Finally, at the end, we know who won.
Apply this model to a schedule. We forecast a range of potential outcomes, with a more probably outcome and a less probable outcome. As the project plays out, the range of potential outcomes diminishes. The most probably path becomes more and more apparent.
Another metaphor I commonly use is a toothpaste tube. If you assess the amount of risk, or uncertainty, associated with the schedule. As events increasingly transform from the potential future to the recent past, the amount of uncertainty goes down. It’s the same as squeezing toothpaste from a tube. At the end of the day, there’s no uncertainty as the project is complete. All of the risk has been squeezed out of the tube.
Figured this out a while back for the forums, but then promptly forgot and shot myself in the foot.
Consider the following scenario:
It turns out the schedule is sync’d to the first task list it finds on the site alphabetically. If you have a task list named something like, My Workflow Tasks, the schedule gets sync’d to that list.
The solution is to always make sure the task list that you want to sync with the project comes in first in the alphabet. Optionally, the other method is to modify the Project Summary Webpart so it points to the correct list – although I’d probably check out option #1 first.
Thanks everyone for coming out to my session on Project Epistemology a couple months ago at the Project Conference. As I discussed in that session, there are often two conflicting views of any Project Server deployment – and I would contend that most conflict within a consulting engagement typically is driven by the conflict between these views.
Put more succinctly, when both parties in a consulting arrangement are operating from a different engagement model, bad things happen.
The first model is simple. It is based on the following points:
What this means is that we have a discrete, defined problem. We can easily place boundaries around it, and the consultant’s job is to come in, design the solution, train a couple of end users, drop an invoice on the desk and run.
The second model is more complex. It is based on the following points:
The challenge in the second model is that we never assume that everyone agrees as to what the fundamental problem actually is. In fact, we don’t even acknowledge that everyone agrees a problem exists. The first step in an engagement of that nature is to work on defining a common consensus as to the problems faced and the priority of those problems. Often times, this requires covering ground that may have been covered already long before the consultant walked in the door.
That’s the fundamental building block upon which to continue the engagement. Once that is completed, we don’t acknowledge that there is such a thing as a solution. Instead, we acknowledge the concept of progress towards a solution, insofar as we can work towards a better future, one where we better understand what the problem is and better provide value to the organization.
What does this mean in the context of a simple reporting engagement? Reporting, more than pretty much any other topic, lends itself to the adaptive consulting model. In reporting, you are typically tying multiple data sets into a single reporting tool, and then presenting that data to your stakeholders. Once they see the data, and they see how it can be manipulated, the questions start. “Can I see it this way?” they ask. “Can we add additional data to the mix to see how it impacts things?”
What that means is that a reporting effort never ends. It just begins. It’s an adaptive exercise continued ad infinitum until the stakeholders have iteratively identified what reports are actually required.
How does one consult in a situation like that? You don’t focus on the steady state solution, which is arguably a myth. Instead, you focus on building a capability. Our job as consultants is to build the capability of developing and modifying reports within the client organization. Once we’ve built that capability and the technology platform to support it, we have done our job well.
For more reading on problem framing as part of enterprise tool deployments, take a look at Kailash Awati and Paul Culmsee’s book, The Heretic’s Guide to Best Practices.
Is a doorway a frame around empty space? Or is it the space that is surrounded by a frame? When selecting a PMIS platform, the same question should be asked. Is a PMIS a series of solutions within an empty white space? Or is the PMIS the empty white space populated throughout with a series of solutions?
For those of you not familiar with the PMIS term, it’s a standard industry name for a Project Management Information System – or any system within your organization that is used to track project data. The PMIS could be a filing cabinet. It could be a series of notebooks kept by engineers. It could be an incredibly complex series of IT tools integrated through a data warehouse and a service bus.
Regardless of the technology underpinning it, the PMIS needs to serve specific functions, whether that is project tracking, portfolio analysis, resource management, risk management, or any one of the other key knowledge areas or processes defined in the PMI literature.
The particular form of a PMIS that’s supported by IT tools is part of our stock and trade. As we see it, this PMIS evolves in different forms.
In some companies, there is no formalized PMIS. In these organizations, there’s typically not a lot of formal project management processes, and most things are tracked in Excel – perhaps with some financial management in a specific tool such as Oracle or PeopleSoft.
In other organizations, there are a wide range of point solutions. This is often associated with (but not exclusively with) large organizations where the project management function has been broken out in to a wide variety of distinct offices. In these organization, there may be an enterprise architecture office, a risk management office, an office that deals with projects just being developed, an office that deals with projects that are more advanced, a reporting office…you get the picture.
The Microsoft platform has a different value proposition in each of those scenarios. Note here that when I talk about the “Microsoft Platform.” I’m not simply talking about Microsoft Project Server – but rather the full panoply of Microsoft solutions: SharePoint, Project Server, Yammer, Power BI, SQL, etc.
For the first kind of organization, the one where there’re not a lot of formal tools in place, the Microsoft platform provides an excellent foundation to build upon. Build your collaboration and document management workflows in SharePoint. Build project scheduling practices and resource management in Project Server. Enhance knowledge capture through Yammer. Report on all of this in the Microsoft BI suite.
The challenge here is that Microsoft in presenting itself as a platform becomes a victim of trying to be all things to all people. Microsoft is great for basic scheduling – but if you are attempting to model critical chain scheduling, you’ll need an add in. If you’re attempting to do Earned Schedule analysis, you’ll need an add-in. If you’re looking to manage large industry-specific design documents, you could do it in SharePoint, but you’ll likely be looking at another solution that’s more tailored to the specific needs of the industry.
For the second type of organization, the kind that already has a lot of solutions already in place, we find value in evaluating them and bringing them into the SharePoint fold. Retire the ones that are superfluous. Integrate the ones that aren’t. At the end of the day, the Microsoft platform provides a single integrated user interface from which to navigate to those tools – and a data structure to enable integrated reporting.
At the end of the day, selecting a PMIS platform is less about point solutions and more about filling the white space within the organization’s project delivery organization.
Enterprises do a lot of things to improve how projects deliver value. They look to define resource capacity calculations, identify the project pipeline, enhance reporting capabilities, etc. The list goes on and on, a veritable smorgasbord of PMI terminology and PMBOK processes. When you back up a bit, and look at each of these options from a macro standpoint however, you begin to see some fundamental trends.
The reality is that from a purely technological standpoint, many of these bells and whistles serve one of two masters.
All of the AHP heuristics, resource forecasting, and dark scheduling arts in the world won’t get significant value out of a portfolio that has not been structured properly. Instead, you’ll be spending a lot of time and energy tweaking a sub-optimized system where you’re still either working on the wrong projects or can’t explain why the ones you’re working on are correct.
Identify which projects belong to which programs….and which programs support which strategic initiatives. Only then, can you really determine when (and how and by whom) the project should be chartered.
Portfolio structuring also helps you become more proactive in your candidate identification.
Caveat: that probably only applies to second tier portfolios – but identifying the difference between the tier one and tier two portfolios is part of the portfolio structuring exercise.
Too often, we walk into an enterprise and see various point solutions for managing specific elements of the project lifecycle. As study after study points out, the key to effective portfolio management is to create an end to end repository for all project information. Start with the idea, move it through selection and out into execution. Gather information throughout the lifecycle. Don’t be creating information from scratch every time you hand the project off from Team A to Team B. Simple.
The data you collect in the PMIS then becomes the grist to enhance the decisions made in the governance layer.
Project Epistemology 