Skip to main content

It

For many years, one of the challenges with technology was to think of software ‘packages’. This pervasive way of thinking inevitably brings us to thinking of software as a collection of features. We even compare one product to another by listing the features on one side with the features on the other.

The idea of having software as a series of interrelated parts that could be made into plug-and-play components of a larger system often meant we would need to do lots and lots of programming of the interrelating software. Our company has focused on solution selling for years, so for us we’re used to asking a client for the problem before we list the solution. But it does make us think around here of software more as a vehicle for creating a solution, rather than a list of features that the client might find attractive.

In the last couple of years, however, there has been sufficient movement in the software business towards more common standards that we can start to think of technology as a “stack” of functionality, and interact with it as the potential for a solution, rather than the fixed list of what can be delivered on the first day.

I recently presented some project management software to a rather large company with a worldwide brand name. This company certainly has extensive project management experience but in the particular division I was interacting with, project management had always been an ad-hoc or project-by-project notion rather than centrally organized. The division’s volume of work has recently increased, however, and the complexity of that work has grown by an order of magnitude. It’s time to make project management a more formal process.

So, I showed them this software, which was rather well received. I showed the software as I often do, after extensive conversations about what the company is attempting to accomplish. Once I’d done the presentation, I turned off the projector and told a story.

“Imagine,” I said, “having to create a new project. You wouldn’t turn on the software we’d just shown you. Instead, you’d click on a link on your corporate intranet portal. The link would present a web-based form for new projects. You’d fill in this form on your terminal. You wouldn’t need specialized project management experience. You might not need to know how to create the schedule and establish the dependencies between tasks, or what a lag is, or that CPM stands for Critical Path Methodology. You’d just fill in this form.

”Depending on who you are, the form might look different. If you were a senior executive for example, certain parts of the form for approvals might not appear. Other parts of the form might only appear depending on other data you’d enter. If the project details you entered had, for example, a place for the cost of the project and that value was, say, more than $100,000 then another part of the form might instantly appear with additional fields of information required to start a project of that value.

“Now, imagine once completing that form that you click on the ‘Submit’ button and depending on who you are, and the data in the form, it is automatically sent to the person in your organization who needs to approve new projects. That person would receive an email in their Inbox. They might see the whole form there or click on a link to the form online in their browser. They would see what you had typed in but they might also see other information. Perhaps they can see right on the form, for example, the value of the project you typed but also the total value of the budget that has been allocated so far for this year. They would see different buttons on the form such as ‘Reject’ or ‘Request more details’ or ‘Approve’ or ‘Forward for approval’. They would click on the ‘Approve’ button and several things would happen. First you would get an email saying that the project is now approved. In your Enterprise Project Management system a new project would instantly appear. It would have the data from the form that you filled out. There might even be a very high level schedule of milestones if those were required in the form for new projects. The stage for the stage-gate methodology would be set to “initialized”. Other key people might be triggered by that event to create certain project documents and so on and so on.

“Now we can do the same thing with change management, budget approval, resource allocation etc.”

There was nothing on the projector. It was a story. But the story was compelling.

“That’s just what we need,” said the representative of the organization.

All of this has become possible and not just with one tool. In fact, if you wanted to make my story into a solution, there are several tools you’d go to look for. They might come from the same vendor or from several vendors.

You’ll need a server-based enterprise project management system of course. That’s a good starting point and there are a number on the market.

You’ll also need server-based workflow engine. Again, there are several on the market that are quite excellent and can be configured without having to be a programmer.

You’ll need a forms-generator for online forms to be able to create intelligent forms that can take actions in the background. Most workflow vendors have such forms-based tools embedded in them or attached to them, but most workflow tools can work with numerous forms tools.

This interoperability is all thanks to the ubiquitous presence of the Internet and the movement from older client-based systems to server-based centralized systems. This has prompted more and more vendors to open their technology. We hear more of the terms “Software as a Service” (SaaS) or “Simple Object Access Protocol” (SOAP). The movement towards Software available as a Service means that whatever functionality is available can be used by different interfaces to create blended functionality. The standard of SOAP and other such protocols means that everyone has a standard syntax and grammar for communicating between products. The end result is the potential to combine the functionality from where you can find it into the solution where you need it, and that’s all possible today.

That’s all the good news.

I know. You were waiting for the bad news weren’t you?

The challenge is what’s implied in my story. The workflow sounded wonderful to my client but, if I want to implement that technology, we need to know what the workflow is. That implies a standardization of process that everyone in the organization agrees to. As I’d mentioned earlier, this particular organization had managed projects in a very casual ad-hoc manner. So getting consensus on what the new project process might be will almost certainly take some work, and consensus is key. Also, we can, in theory, proceduralize almost anything, but the law of diminishing returns takes effect in here somewhere. There will come a point where making a formal automated process of one more procedure rather than leaving it to be managed casually won’t produce any more efficiency. There needs to be someone central to make the decision on what that point is.

Who will make the final decision on what to proceduralize? Who will have the final say on what a particular process will be? What will be the process to change or add to the process? If the processes we’re discussing will touch several departments (such as Finance, or HR) instead of just project management, then who will be the liaison for those departments? Who will be the keeper of the process? What is their authority in the organization?

This is why, when I talk about enterprise project management and what’s possible, I inevitably talk about it as a change management project rather than as a technology project. At its core, we’re asking the organization to change how it works and possibly how some core aspects of how it works. That change is always going to be a bigger challenge than the technology required to deliver the solution.

What’s important to know? That it’s now possible to blend these technologies together and as a result bring the project management process to levels of the organization that will never see or need to understand a GANTT chart or a PERT diagram.


Chris Vandersluis is the founder and president of HMS Software based in Montreal, Canada. He has an economics degree from Montreal’s McGill University and over 22 years experience in the automation of project control systems. He is a long-standing member of both the Project Management Institute (PMI) and the American Association of Cost Engineers (AACE) and is the founder of the Montreal Chapter of the Microsoft Project Association. Mr. Vandersluis has been published in numerous publications including Fortune Magazine, Heavy Construction News, the Ivey Business Journal, PMI’s PMNetwork and Computing Canada. Mr. Vandersluis has been part of the Microsoft Enterprise Project Management Partner Advisory Council since 2003. He teaches Advanced Project Management at McGill University’s Executive Institute. He can be reached at [email protected]. This e-mail address is being protected from spam bots, you need JavaScript enabled to view it.

And the Rant Goes On!

In my last blog, I complained about how the two words “Project Manager” can mean such different things to different people. Let me continue my rant on perceptions of the role of the project manager. Well, first of all, why am I making such fuss about this? Because it is just too important to ignore!

A few years ago, at the time of my getting pretty bored with my well-paying full time job, I read Peter Block’s famous Flawless Consulting. The most important thing I learned from it follows: happy and prosperous consultants never position themselves with client as a “pair of hands”.

Far too many of my colleagues in project management are happy with the “facilitator” role. They maintain project schedules and set up meetings, keep minutes and file timesheets. I don’t know why anyone would like such a mind-numbing, boring, low-value job. Fine, perhaps, for a young kid right out of the school, for a short time, just to figure out how the corporate world works, but for a mid-career professional? Please!

I sometimes receive calls for recruiters and am constantly amazed how low project managers’ rates have fallen! I recently heard that banks pay as low as $60,000 and that it is dragging the whole market down. Except, if we are talking about the facilitator role, 60K is just too generous. I can get a clerical person do the same job for much less than that.

What makes sense to me, in terms of positioning, is the “taskmaster” project manager. As an executive or a project sponsor, I want to see someone stepping up and taking on the responsibility of running a project for me. There are clearly defined boundaries, and if the issue is outside of them, I am made aware and expected to provide guidance. This is a partnership, and I rely on the project manager as much as he or she relies on me. A good taskmaster is worth a lot.

The positioning of the project manager as a “mover and a shaker” is appealing and potentially very lucrative, except that:

  1. If such expectation comes without true empowering, which is often the case, the project manager will certainly under deliver (and possibly shorten his expected lifespan).
  2. Inevitable risks outside of the project manager’s control become the project manager’s problem. How do I control things outside of my control? This can get very stressful.

These points are so serious that I would never take on a mover and shaker role unless I have dealt with these issues, no matter how much I like the feeling of making things happen. And I like this feeling a lot!

The Proximity Principle: Continuous End-User Involvement and Project Success

In my previous blog entry, I mentioned the importance of managing perceptions. I also wrote that not doing so was the main cause of why only one project out of three was considered successful by major stakeholders, according to the Standish Group’s Chaos Report 1.

So, if we have to manage perceptions, where and how should we start doing that? The Chaos Report gives us pretty good leads on that, so, I am still amazed to find in my project management workshops that not even one participant out of 100 knows about the Chaos Report, its contents and conclusions (based, by the way, on data and observations on thousands of projects).

The report identifies the involvement of end-users as number one in its top ten list of key project success factors. Yet many project managers and their sponsors still shy away from this obvious tip. On too many projects still, project managers meet, at the start of the project, some so-called representatives of these ultimate project customers to discuss rapidly THEIR operational requirements. They will not be in touch with end-users again until much later in the project, only to find a very uninformed, displeased, and distressed party in full “resistance-to-change” gear. There is then a lot of damage control to do to regain end-user trust and ensure that they will commit to materializing project benefits from the deliverables “imposed” on them.

End-users involvement must be more than that. Successful project managers have long realized that, in this changing world of ours, customers/end-users also change their mind along the way and must also understand that conditions in the project environment change for all sort of uncontrollable reasons. Both project managers and their ultimate customers must be ‘in sync’, preferably in a continuous manner, in order for the former to satisfy the latter.

Ensure with your sponsor that you get proper end-user representatives on board and keep them involved in your project as it evolves. I call that the Proximity Principle and its functioning is quite well explained by Scott Ambler in his landmark article: Agility for Executives 2. Do that and you will automatically get high quality deliverables (and highly satisfied end-users perceiving the same deliverables as you), while keeping the risks of not meeting requirements as low as possible. Do this also with all other major stakeholders and you will effectively manage perceptions and deliver successful projects over and over again.

1 www.projectsmart.co.uk/docs/chaos-report.pdf
2 http://www.ddj.com/architect/184415034?cid=Ambysoft

Creativity Cannot Be Scheduled!

And more often than not problems take longer to solve than you’d expect.

The sort of problems I’m speaking of is often seen in projects where new technology is commercialized or where the availability of a new service depends on the introduction of new technology. It’s the type of problem where an obstacle presents itself and progress on the entire project is affected. Many times the barrier threatens a core feature the sponsor is eager to see.

So what can we as project managers do to deal with these very ‘hard to resolve’ problems that invariably arise?

There are several ways to address problems that arise over the course of a project. Each problem has its own attributes and requires its own approach to solving. But there are some generic actions you can take. These center around the notion that projects require a team-based approach to problem solving and a project manager can facilitate team performance.

The first and foremost consideration is that the team solving the problem needs to be a ‘team’. This means there has to have been something else they’ve done together prior to addressing the ‘big’ problem. I tend to look for things to nurture teamwork prior to taking on more challenging issues.

We’re all aware of the traditional phases of the team including forming, storming, norming and performing. We know the project team will drift in and out of these stages, depending on the dynamics of the environment and situation. If team members have a precedent on what to do to resolve smaller matters, then alignment of the team to focus on the more serious issue will be easier and faster.

Essentially we want to ensure team dynamics will not delay starting the problem-solving process. We do this by facilitating the team through as many ‘cycles of learning’ together as possible, early in the project. Here the cycles of learning apply to how members settle into their roles, share information and relate to each other in a synergistic manner. If they’ve experienced it before then revisiting it again for another issue is easier and hopefully progressive.

Another proactive approach is to mitigate the risk of technical issues through risk analysis and assessment. Unproven technology and integration issues can be difficult to uncover as part of the risk management process. However, the development methodology (i.e. agile, waterfall, prototypying, etc) selected for the project can help. For example, prototyping specific aspects of the technology or its integration can provide very illuminating results early in a project life cycle. Often these foreshadow where development ‘challenges’ can be expected. Schedules and budgets can be adjusted much earlier.

In closing, while good risk management is a great tool to identify potential problems, building a team ready and able to solve problems quickly and effectively is essential to deal with the uncertainty of scheduling solutions to problems.

 


Mike Lecky is a consultant at The Manta Group, a management consulting company specializing in IT governance, Project and Portfolio Management, Service Management, Risk and Compliance. Mike has degrees from the University of Waterloo (BScEng), The University of Western Ontario (MBA) and the University of Liverpool (MScIT). He worked for 12 years in aerospace electronics and as a Project Engineer managed several general aviation and US Military contracts. He teaches project management online with the School of Applied Technology at Humber College. Now, with over 25 years experience, he is a PMP and an information security professional (CISSP) and has a broad range of program and technology implementation experiences in the high tech and service sectors. Mike can be reached at [email protected]

The California Gold Rush and New Year

Editor’s Comments

It’s that time again in the PMO. The previous year has been reviewed at length and resolutions have been made for and by the PMO but, as Terry Doerscher suggests in Last of the 2008 New Year’s Resolutions, it’s time to take a look at what resolutions the PMO manager might make that would benefit the rest of the PMO team in the coming year.

The California Gold Rush caught the world’s attention in the middle of the 19th century. It made many rich but shattered the dreams of many more. From those dreams sprang the modern city of Roseville with a population today of more than 104,000 citizens. As Demien Entrekin points out in Former Gold Rush City Has Big Plans for the Future, the city now has over 180 IT projects underway in its project portfolio.

Blogger Andrew Miller talks about the problems in being brought in to run somebody else’s project after the contract has been signed. And David Barrett discusses the importance of that critical soft skill – effective communication. Visit our Forums and give us your views and tell us what you think about the PMP designation in our Poll Question.

We hope you enjoy this second 2008 posting of Project Times and please take the time to email us with your thoughts and suggestions.