Adding Value

My MacBook has a sticky note displayed in the corner at all times as a constant reminder of successes and failures.

"What we must decide is how we can add value and not how valuable we are"
- Edgar Z Freidenberg

These days so many Project Managers learn Microsoft Project, hound resources to complete tasks, record issues in Excel, take a test and voila!  Look how valuable I am!  I am a Project Manager!

Let's say I come to work for you. Obviously you think I can contribute to the success of your business, and I think I can contribute as well. But if on my first day I walk in and think, "they will never do this without me" will I set the expectations for failure?

How do I achieve any value with that statement? When I sit at my desk on Day 1, I have not yet achieved anything! I have only promised to achieve and add value. So I start about the business of adding value.

Ok, so let's say I walk in on Day 180. I have a couple wins under my belt. You call me first when you have a new project to discuss. Now am I valuable? You bet. But you cannot put my value in the bank, or declare it to shareholders. You can tell the shareholders that you are backing me for a big project because of my previous record of adding value, but the shareholders will still judge us both based on the end value added by our project.


I add value by delivering. I can achieve it best with transparency; if I know the business strategy. Perhaps our company needs entry into a particular market and profits are not key. Maybe we must conform to government regulations and exact requirements and costs are critical. We might even take a smaller project in hopes of getting more work at the client. I will plan the project so that the most critical elements will get the most attention. I will tailor my day-to-day management based on the overall goals and objectives of the project, not by blindly following a canned methodology.

I also add value by bringing information to you, so that you can make informed decisions. "Did you see the article that the government has extended the deadline for compliance?" "It looks like our competitor just got that big contract we were hoping to get." "Companies X, Y and Z just announced products in our market."

Companies exist to make profit. And management must produce that profit. Seems simple, but not all workers care about this. As a business owner, I care. I always look for cost cutting measures in projects that won't affect quality, and ways for utilising staff better.  

Perhaps Dr Freidenberg wanted us to keep achieving: Set expectations and never rest on our laurels. I can rest when I'm dead. Until then, I'll keep adding value.

The SharePoint Project

This week I attended the Australian SharePoint Conference at the Hilton Hotel in Sydney. I've decided this is the last year I will be an attendee. Next year, I plan on presenting.

I am currently managing my fourth "SharePoint project". This is somewhat of a misleading proposition. As a former application developer and business analyst, I have always tried to deliver based on business objectives. As a Project Manager, I need to understand why there is a "SharePoint Project."

What is a "SharePoint Project?" SharePoint is a platform. Thankfully, this is the main message out of the conference to those just beginning to dabble in the technology.  One session estimated, by a show of hands, that 40% of the room was on 2007, 40% on 2010 and the rest were "thinking about" going to SharePoint. This message is for that last 20%.

By the time I'm hired as the Project Manager, the platform has already been "installed." Infrastructure guys (and I love you) have found SharePoint on the Windows server and "turned it on". Now to tell someone how to use it!

Voila! The SharePoint project is born. Some sites get created; the webmaster thinks it would make a great intranet; the document/records lady notices you can tag stuff with metadata. The CIO throws a barely six-figure sum at the budget and asks the Infrastructure guys to do this in their spare time.

No wonder so many people hate SharePoint. It's treated like Infrastructure.

Paul Culmsee, in his Day2 keynote speech, noted that things like installing servers are simple. You plug it in and it works. It's basically the same every time. Sure you have to hook up dummaflobbers and whatsits, but servers are interchangeable for many purposes. And infrastructure guys are great at knowing all this.

Things like Exchange/ Outlook are little more complicated. You configure it based on requirements that are predictable. People want to get mail and send mail. The requirement and business objective is that the thing works. I don't have to ask anyone what "success" looks like.

SharePoint implementation, however, is complex or sometimes chaotic. The requirements are many. The Webmaster wants a good content management system; the Enterprise Architect wants good information architecture; the Records Manager needs a single source of truth. SharePoint has suddenly become the solution to everyone's problem.

But that's just it. It's a solution. You need a problem to solve. SharePoint can be configured and adapted to do just about anything, but you just don't know what that anything is yet. 

Mark Miller, the editor of EndUserSharePoint.com, is right in saying that business objectives should drive the use of the platform. If you're not careful, you could end up blow-drying your pizza, or microwaving your dog.

The platform needs to have a strategy, a reason to exist.  From the strategy, projects branded with the business purpose in mind can be launched. Each project - document management, intranet, business process workflow - should have its own business objectives and a determination made as to whether SharePoint is the right platform. 

Next year at the conference, I'd like to see less geeks and more business folks. Vendors should be inviting their contacts along to see how SharePoint can provide the platform for the solution.  I'd like to see Governance replaced by Strategy; Workflow Management replaced by Business Process Implementation; Site Branding replaced by Project Branding. Let's start using the term "SharePoint" in context as the middle-bit between Windows and the applications that run on it.

End Users can then be taught the Business Solution. And no one, other than the Infrastructure guys, should ever care that it's called SharePoint.

What would you like to learn about from a SharePoint conference?

Project Manager Time Quadrants

In 1995 I managed my first Information Technology project. It was for an organisation that did not have formal methodology experience, but they were pleased that I did.  It was very much a 1 to 1 relationship between me, Project Manager/ Business Analyst and the Project Sponsor/ Subject Matter Expert.  My focus was on capturing requirements and feeding them back to the developers, managed by another line manager. I spent nearly all of my time managing the relationship with the key stakeholder, and delivering the project; almost none managing the relationship with the delivery team and administering the project.

By contrast, in my last project, I had 15 high-profile stakeholders and subject matter experts. My delivery team was spread across 3 divisions with 3 different managers. I was considered one of the subject matter experts in the technology, and this organisation has a large and complex project reporting structure.

How is one project manager meant to fulfil all the roles in the Project Management life cycle?

Generally, there are two things a project manager spends time on: Relationship Management and Delivery Management.

Relationship Management focuses on who you spend your time with to get the results you have promised for the project. This can be Stakeholder-focused such as the Project Sponsor, Steering Committee or End users or on your project team who are providing the deliverables.

Delivery Management focuses on how much time you spend providing feedback on progress. Administrative focus is heavily-based on methods, formulas, EPMs and reports. Delivery focus is based on showing frequent and accurate results, such as prototypes and releases.


If we plot these on a grid it looks like this:

So let's say you spend 100% of your time updating Gantt charts, checking on task status, writing reports and updating budget spreadsheets. We call this the Project Administration Quadrant. More time is spent on reporting and communicating with the team.

The opposite extreme is the Stakeholder Manager Quadrant. The Project Sponsor or Owner has hired you, the Project Manager to turn a mish-mash of opinions into a functioning system, application or network.  This is the hardest of the roles because it requires up to 100% of your time setting and managing expectations of the stakeholders who want (or don't want) the project to succeed, whilst focusing on the delivery of their objectives. You have little time with the team, and little time to report on progress. If the Stakeholders are high-profile, a Project Director might be brought in to manage the individual project managers. This is the Project Manager role I prefer, but with a Project Director in place (or with me as the Project Director).

If your time is spent managing the delivery team and the deliverables, you fall into the Team Leader Quadrant.  These are usually straight forward requirements with a small number of stakeholders.


Lastly, the Program Management Quadrant requires a lot of administrative time and management of stakeholders. Program Managers rarely interact with the delivery teams or the act of delivery unless problems arise.

So in which Quadrant does your current project reside? In the next blog, I'll show you how to use this quadrant for your project planning.

Risk management has killed project delivery

How many different points of risk management does it take before a project is properly risk managed?

I recently wanted to acquire expert services for a project. I have completed similar projects before and these projects take about 3 months from the time you get requirements, and with full cooperation of the necessary teams. These I had already established.

Despite the fact that I am a veteran, certified Project Management Professional (in two disciplines) I was forced to undergo the rigid "risk management" processes of the procurement department under the guise that it was "required."

Six weeks later, (now 5 and half months after my project start), the evaluation team selected a vendor through the rigourous process and I was prepared to make an agreement. Since this vendor had little experience with the organisation, I mitigated the risk by awarding the work in two sections: three weeks, and then the remainder to be re-quoted at the end of the first period.

This vendor has a head agreement, so a contract with terms and conditions is already in place. With a firm agreement on what was to be delivered in the first three weeks, I sent the work order back to the vendor, expecting a one day turnaround.

The risk management team from the vendor clearly re-vamped the entire work order, adding resources that I did not want, and deleting resources that I required.

They mistakenly thought that volume was a replacement for quality.

In the end, I stopped negotiations with the vendor (by this time, half of the three weeks had passed) and signed up another vendor who could provide me with the quality resource I needed right away.

Sadly, had I been able to trust my own risk managment experience, I would have been able to engage the second vendor two and a half months ago, and the project would be well underway.

These days, risk management is in every aspect of a project. Or rather risk avoidance, which is only one of the risk strategies.

Should we do the project? If so, what things could go wrong if we undertake it? What if an earthquake hits the east coast of Australia?

News flash: If an earthquake hits Sydney, there's a much bigger problem than whether or not a $300K website is up!

Ok you want a vendor? Well you have to manage the risk that the vendor won't deliver. And guess what? The vendor is trying to manage the fact that you, the project manager, don't know what you are doing and will not give the vendor what they need in order to deliver.

The blame game starts before there is even an agreement to do work.

Wasn't the purpose of getting certified to prove that I was capable of making these types of decisions? How can I be a true professional when I am constantly being second-guessed by over-cautious lawyers?

Ok, I agree it may be necessary sometimes. Ten million dollar projects are often executed and fail to deliver their required results. But maybe it's not anyone's fault. Maybe it's just that the market or the business or the rules changed in the 5 years it took to execute the project. You can mitigate every risk and still not win.

I know one thing, with a 3 month delay on a 3 month project, this is how I lose credibility for delivering.

I guess that is a risk I should have mitigated instead of accepted.

Question: How do you mitigate the risk of being risk over-managed?

Welcome to Project Mom!

Greetings,

As a full-fledged, dyed in the wool, dual-certified (Prince2 and PMP) Project Manager, I welcome you to my world.

With over 15 years as Project Manager, and over 20 in Information Technology, there is not a single case study that's been presented that I have not seen.

History repeats itself. Continuously. With certainty.

The role has changed from being able to deliver scope on time and on budget, to one that concentrates on setting expectations, coddling stakeholders and reducing the impact of impending failure.

Enjoy my musings. And take away what you will.

Follow me on Twitter @projectmom