Tag: Career

The CEO of Microsoft, Steve Ballmer got this year’s slogan going with a bang, “We’re all in!” he cried to the crowd early this year.  It’s a poker analogy of course.  “All-in” refers to betting all of your chips; putting all your money on the next turn of the cards.  You’re betting everything that you’ve got the winning hand.

What Microsoft has been betting on is moving many of its products to the “Cloud” where users can consume them online.  As I was talking about this new message of Microsoft’s to my wife it prompted the obvious question, “What is the cloud?”  I had to think about it a minute.  What does the IT industry mean when we talk about Cloud Computing and what are the implications to the project management software industry and to project managers in general?

First of all, like almost anything in the IT world, there are numerous meanings; the cloud designation comes from network diagrams which had to depict connections to something out in the Internet. 

So the “Cloud” can just refer to the Internet in general as in “somewhere out there”.  In recent years though, applications that have been only available via the Internet have sprung up.  There are numerous examples.  Salesforce is a CRM, Contact Management System that isn’t installed at your local office.  You pay a subscription as an organization and then access the application through your Internet Web Browser online.  Google Apps is a suite of Applications such as Word Processing, Spreadsheets and Presentations that is available only through your browser.  Microsoft’s office.live.com offers Word, Excel and PowerPoint this way also.  Almost everyone knows about Hotmail, Yahoo Mail or Google’s Gmail.  These are all Internet-based email systems that you don’t install in your office but rather access through an Internet browser or application of some kind.  All of these examples are applications that live “in the cloud”.

One of the big concerns over cloud-based applications has been the security of the information.  As many of us have seen in the past, social networking systems like Facebook are having its clients pay for its “free” service with a bit of their privacy.  So, a new term sprang up, “private clouds”.  This seems like a contradiction in terms but actually it’s referring to something of a mix of terms.  A private cloud application is one which is not installed on your premises on your own servers, but rather is installed on the servers of a service provider who dedicates that server for your organization’s use.  So, the privacy of the information, even though it is being transmitted in some way over the Internet, can be made much more secure.

OK! So that’s cloud computing, but I’ve yet to mention project management applications.  Don’t worry, they’re there.  There are a number of project management applications that are made available in both the Internet Cloud and Private Cloud models.  Many clients we know are now having their enterprise project management applications such as Oracle’s Primavera or Microsoft’s Project Server hosted by a third party service provider.  There are also software vendors who have designed their whole application to be available only through online subscription and your Internet Web browser.  Take a peek at Canada’s AceProject (www.aceproject.com) based in Quebec city or Daptiv (www.daptiv.com) based in the US in Seattle.  There are many more examples which you can find easily through an online search.

Your own applications, even though internally developed can also be moved to the cloud.  There are many environments to choose from.  Take a peek at Amazon’s EC2 Elastic Computing or Microsoft’s Azure environments, for examples.  You can get your own virtual server at Amazon or a complete computing environment at Microsoft.  More and more organizations are finding it attractive to offload their capital costs to such services in favour of regular operational costs as a method of improving cash flow and not tying up working capital in actual equipment.  “Shift your CapEx to OpEx” say the salespeople. 

With enterprise project management systems becoming more and more complex to support internally, there is some attraction to all of these models.  Enterprise systems typically depend on a “stack” of technology.  Take Microsoft’s Project Server as an example.  We depend on Windows Server, SQL Server, Activity Directory, SharePoint, Internet Explorer and Exchange Server to make all the features in Project Server appear. If we can put responsibility for all of the server-based portions into the hands of a third party who specializes in such things, this can become attractive.

We estimate that more and more enterprise applications will not only become available from a cloud-based service, but that more and more organizations will insist on such applications being subscribed to that way, so look for more and more of your enterprise level applications to appear in the cloud.  That being said, I don’t expect that at any time in the medium term we’ll see a movement completely away from locally installed enterprise systems.  Also, regardless of what’s in the cloud, there will always be a market for individual project management tools.

So, what should you do?  For the moment, probably not much that’s different but every organization looks at their internal tools every few years and I predict that people who are looking in the 2012 to 2015 range of time will be thinking about whether to install those tools in-house or in the cloud.

There are some clear advantages to installing in the cloud and a few things to be aware of. 

On the advantage side, the maintenance effort of keeping the enterprise system available, patched, upgraded, backed up and operational falls to someone else.  Suppliers of such solutions also keep staff experienced in the maintenance of the tool, so you don’t need to get stressed over acquiring those skills internally or keeping them current.  There’s also a financial consideration.  Installation of a new enterprise system is typically quite expensive; requiring hardware, operating systems, databases and a range of other supporting technology.  Expertise must often be hired to do the basic installation before you can even think about configuration of the tool for your particular use.  These costs can be amortized over time in a cloud-based model and woven into the regular subscription fee.  Of course, if you evaluate the total cost of ownership, it may appear more costly to pay month-by-month over the long term.  You’ll need to check your business case carefully to ensure you’ve allowed for all the costs and cost savings of each option.

On the disadvantage side, you’ve got a few basic things to think about.  First, working with an application in the cloud means that every one of your users has to be able to get to the cloud.  That means Internet access to the application without the firewall or other restrictions keeping you from it. Security also becomes a concern.  If you’ve got a contract in certain industries (like Defense or Healthcare) then you may have legal requirements for security that must be complied with.  If your organization is used to doing custom modifications to your applications then that may be a factor also.  Some cloud-based applications are not designed to be modified by the end-user.  This may be more restrictive than you’re used to.  For some applications, bandwidth and performance may be issues.  One common question is to find out where the application and its associated data will be physically located.  Just because a service has an address that is local to you doesn’t mean they house their data there.

Cloud-based applications are here to stay and you’ll need to include “Should we move it to the cloud?” as one aspect of future enterprise project management and enterprise project portfolio management applications.

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]

Much has been written about the potential for a contentious relationship between the project manager and business analyst. If you have been a business analyst or project manager for any length of time, then you have probably experienced some of this tension for yourself, particularly if you have previously performed both roles. It can be difficult to find a happy medium when so many of the tasks seem to overlap between the BA and PM role. For example, PMs are used to managing relationships with customers and sometimes delve into requirements during status updates when the BA is not present. BAs can overstep their bounds by adding scope without the knowledge of the PM, thereby impacting project resources and timelines. It doesn’t have to be like this.

This article is the tale of two professionals – a BA and a PM – and how we learned to work together to form a strong partnership to deliver superior results for our customers. Our goal is to provide tips that worked for us that may work for you. This way you can recognize when you are in the storming phase and quickly take action to move you into the norming and performing stages so that you can excel in your work relationships.

Group Development Model

First, let’s start with the basic premise that all teams go through a similar pattern when learning to work together – as illustrated in the Group Development Model developed by Bruce Tuckman in 1965. The Group Development Model states that there are four phases of team development: Forming, Storming, Norming and Performing. As a team comes together they enter the forming stage where team members are introduced and get to know each other. This phase is usually brief and leads to the storming phase where team members jockey for position and test the boundaries of authority. In the storming phase conflict comes to a head and usually leads to a make it or break it point for a team. In fact, many teams don’t successfully navigate their way through this stage. For teams that can navigate these stormy waters, they find themselves entering the calm waters of the Norming stage. This stage is where team members dig in and focus on getting the job done. A leadership hierarchy is firmly established and teams can concentrate on the task at hand. Most teams stay in this stage for the remainder of the project. Some teams are fortunate enough to enter the Performing stage where true team synergy happens. Team members are inter-dependent and are able to handle the decision making process with little direct supervision. Of course, teams will move back and forth through the different stages of team development as circumstances change: new leadership, loss of a key team member, or project completion.

Our Story: Lessons Learned on the Front Lines

Forming a Relationship: Our relationship began when we were assigned to work together on a large, strategic IT project. Joan was assigned as the project manager and Renee was given the responsibility of the lead business analyst for the project. Throughout the year, the project team consisted of one PM, three to five business analysts, and numerous development and Quality Assurance resources.

Renee’s Perspective: The beginning of a project always brings uncertainty, ambiguity, and many questions. This project, with its strategic significance, was no exception. Joan and I were acquaintances but had never worked closely on a project together. In fact, the one brief time we had worked together, I was a complete emotional wreck that Joan had to talk off the ledge to get the job done. I was sure she considered me to be a complete flake! I didn’t know how much lee-way she would give me as a lead analyst and we didn’t formally define our roles and responsibilities. Our biggest mistake! This lack of definition, of who was responsible for what, led us right into the storming phase of the project.

Joan’s Perspective: Getting to know the team leads is a significant task. When forming a new team, I try to understand the leads. What makes them tick, will they follow through on tasks, are they growing into this role or are they experienced, will they truly be dependable leaders that I can rely on or will I need to help them along? Of course, the answers to these questions develop as you begin working together. In the beginning I may assume a more dominant role to be sure the team is heading in the right direction. This may mean setting up and facilitating sessions to determine and lay out scope. Now, if you are a trained PM, you know scope management is a key responsibility. However, BAs also assume this responsibility.

Stormy Seas Ahead

Renee’s Perspective: Being a business analyst lead on a team can mean different things to different people. To me, it meant taking responsibility for all of the analyst tasks on the project, ensuring analysts were meeting their milestones, working with analysts on the team to facilitate problem solving, addressing business needs, and, of course, writing requirements. During the beginning of the project, I noticed that Joan would often approach each analyst, discuss requirements approach, follow up on open items, and sometimes hold meetings where requirements were discussed without me. I felt like I was not being given the opportunity to lead the requirements effort. To address the issue, I pulled Joan aside after a meeting and brought forth my concern. I wanted her to be aware that I needed more of a leadership role and that I would like to work together as more of a partnership. While it is sometimes difficult to bring forth concerns that may cause conflict, I stuck with the approach of addressing the issues by bringing up specific situations and how I felt about them – not by accusing or blaming Joan. I knew her intentions were good – she wanted the project to be successful. I also knew there were two possible outcomes – Joan would either hear what I had to say and suggest a better approach to our relationship or she would become offended, defensive, and potentially make my life miserable. Fortunately, Joan is a level-headed person and listened to my concerns and suggested some actions we both could take to make things better.

Joan’s Perspective: Realizing that I needed to move the project ahead, I quickly set up scope planning sessions. On prior projects I had also coordinated the work assignments for the BAs on the team, discussed and helped set approach and, in some cases, I would be the primary contact back to the business sponsors on key requirements and scope changes.

I was genuinely concerned when Renee confronted me on my leadership role and how it overlapped with how she perceived her role. I knew we couldn’t be productive and have a solid team if we continued bumping into each other by trying to assume the same responsibilities. I was glad she felt comfortable enough with me to be open and honest and I welcomed her willingness to take on more responsibility by managing the tasks of the other analysts on the team.

Wanting to develop a solid, strong working relationship, we discussed in more detail what she wanted out of this project, as the lead BA and how we each picture our roles. I also expressed the concerns that scope management was a key factor to my role. So, we agreed that Renee would lead the scope meetings, but that I would be invited to all meetings. This way, I would be in touch with decisions, understand the project and be able to actively create a Statement of Work, maintain risk, issue and change logs and put together successful project plans.

I also suggested that we have weekly lead status meetings. This would give us an opportunity to connect one-on-one to openly discuss any issues we had with each other, project concerns, or just to get to know each other. Simple questions such as, ‘Renee is there anything you are expecting from me or roadblocks you are encountering that I can help remove?’, or more simply, ‘What do you have for me this week’ went a long way in building a strong relationship. We started understanding each other and how we can best work together and with others on the team.

The New Normal

Joan and Renee’s Perspective: As the year progressed we applied the solutions we agreed upon in storming.

We were very committed to our lead status meetings. Even though we did have to move them on occasion, we always had a weekly update. Through open communication we brought forth concerns without fear of repercussion or accusations. We began to understand each other and what makes each us tick, which led to trust and assurance in each other’s role.

The benefits of this led to a strong leadership team who weren’t in conflict with each other, and this helped the rest of the team focus their energy on getting the job done. In the end, the entire project team delivered what the customer needed when they needed it. Success!

Taking Care of Business – Performing at Our Best

Joan’s Perspective: A year has passed since Renee and I stormed through our first project together. We have grown together, learned from each other and trust one another. We are now on another large initiative together, where Renee is the lead BA and I am the PM. We continue to implement our key lessons learned:

1. Roles and Responsibilities defined: We held a team kick- off where the first thing we did was put together and agree upon roles and responsibilities. The matrix contained stakeholder, PM, lead BA, lead developer and other key roles.
2. Meet Regularly: Renee and I continue to have weekly status meetings. These have become instrumental in being in tune with the progress of the project from both of our perspectives. The one-on-one status has instilled trust, respect and friendship between the two of us.
3. Collaborate: We have learned to collaborate on key aspects of the project. We talk about approach and agree on it together, at the onset of a project. We facilitate and partner on the initial scoping meetings, discussing who will do what, when. We continue to bring forth concerns without blaming each other and creatively work out our differences.
4. Trust: Renee has completely taken over the leadership and work assignments for all BAs who are assisting her on the project. Through working closely together, I know we share the same goals and I trust her ability to see things through.

The greatest benefit is the fact that we truly enjoy working together and often request each other on projects.

Learning to work together is no easy task. The common denominator is communication and accepting the fact that you cannot take the storming process personally. You need to work together to resolve healthy conflict and work to a resolution that is acceptable for everyone. If you cannot do this, you will not be able to reap the benefits of the norming through performing process.

Don’t forget to leave your comments below

Renee Saint-Louis is a Sr. Systems Analyst with a subsidiary of The Schwan Food Company where she established and led an Analyst Center of Excellence. Prior to joining Schwan, Renee served as the Requirements Elicitation Practice Lead at a large insurance company. Renee has been a practicing analyst for more than 10 years. Contact:[email protected]

Joan Demuth, PMP, is a Senior Project Manager with a subsidiary of The Schwan Food Company where she leads numerous continuous improvement initiatives as well as serves as the lead project manager on several multi-million dollar IT projects. Prior to becoming a Project Manager, Joan served as a Business Analyst for more than 7 years. Joan has a Master’s Degree in Business Administration from the University of Sioux Falls. Contact: [email protected]

As a project manager, you need to manage people, money, suppliers, equipment—the list is never ending. The trick is to be focused. Set yourself five personal goals to achieve. If you can meet these simple goals for each project, then you will achieve total success.

These goals are generic to all industries and all types of projects. Regardless of your level of experience in project management, set these five goals for every project you manage.

Goal 1: To Finish on Time

This is the oldest but trickiest goal in the book. It’s the most difficult because the requirements often change during the project and the schedule was probably optimistic in the first place.

To succeed, you need to manage your scope very carefully. Implement a change control process so that any changes to the scope are properly managed.

Always keep your plan up to date, recording actual vs. planned progress. Identify any deviations from plan and fix them quickly.

Goal 2: To Finish Under Budget

To make sure that your project costs don’t spiral, you need to set a project budget at the start to compare against. Include in this budget, all the types of project costs that will accrue, whether they are to do with people, equipment, suppliers or materials. Then work out how much each task in your plan is going to cost to complete and track any deviations from this plan.

Make sure that if you over-spend on some tasks, that you under-spend on others. In this way, you can control your spend and deliver under budget.

Goal 3: To Meet the Requirements

The goal here is to meet the requirements that were set for the project at the start. Whether the requirements were to install a new IT system, build a bridge or implement new processes, your project needs to produce solutions which meet these requirements 100%.

The trick here is to make sure that you have a detailed enough set of requirements at the beginning. If they are ambiguous in any way, then what was initially seen as a small piece of work could become huge, taking up valuable time and resources to complete.

Goal 4: To Keep Customers Happy

You could finish your project on time, under budget and have met 100% of the requirements—but still have unhappy customers. This is usually because their expectations have changed since the project started and have not been properly managed.

To ensure that your project sponsor, customer and other stakeholders are happy at the end of your project, you need to manage their expectations carefully. Make sure you always keep them properly informed of progress. “Keep it real” by giving them a crystal clear view of progress to date. Let them voice their concerns or ideas regularly. Tell them upfront when you can’t deliver on time, or when a change needs to be made. Openness and honesty are always the best tools for setting customer expectations.

Goal 5: To Ensure a Happy Team

If you can do all of this with a happy team, then you’ll be more than willing to do it all again for the next project. And that’s how your staff will feel also. Staff satisfaction is critical to your project’s success.

So keep your team happy by rewarding and recognizing them for their successes. Assign them work that complements their strengths and conduct team building exercises to boost morale. With a happy motivated team, you can achieve anything!

And there you have it. The five goals you need to set yourself for every project.

Of course, you should always work smart to achieve these goals more easily.

Don’t forget to leave your comments below

Jason Westland has 15 years experience in the project management industry. From his experience he has created software to help speed up the management process. If you would like to find out more, visit http://www.projectmanager.com.

Project managers generally have oodles of responsibility but limited authority. They seldom have any significant control over the five W’s (the who, when, what, where and why of the planned change). Their primary focus is usually figuring out how to take the many diverse (and often unstated) wishes of the project stakeholders and juggle those into a timely, cost-effective and quality implementation. Something like herding cats! Yet, for all the obstacles PMs face, their greatest challenge (and opportunity) is to become the sponsor’s best friend. And, vice versa.

Over the next few months, we’ll explore the differences great PM s did make (or could have made) to real world project experiences. We’ll look at how they worked with (or could have supported) the project sponsor and the other project stakeholders to ensure a successful implementation. But first, some background so that we can share a common understanding and apply a standard set of principles to the project experiences. 

I’ll use my Project Pre-Check practice as the vehicle for assessing project and PM performance. It is based on this premise: If the stakeholders for a given change are actively involved in and agree with each decision, and all the vital decisions are addressed, the project will be successful. Great PM’s use these fundamentals every day.

Project Pre-Check relies on three building blocks to ensure that premise becomes a reality; the stakeholders, the processes that the stakeholders follow and the decision framework that facilitates stakeholder decision-making.

As a sponsor, I look to PMs to bring this foundation to every project they tackle, using a formal practice like Project Pre-Check or their own combinations of wisdom, experience, intuition, tools and techniques.

Stakeholders

Having the right stakeholders engaged in and committed to a project is absolutely fundamental to project success. I expect PMs to ensure that the stakeholders are identified and actively engaged from a project’s inception to completion. So, what’s a stakeholder? They are the influencers and decision makers. Project Pre-Check includes four roles: sponsor, change agent, target and champion. 

A Sponsor is a manager who legitimizes the planned change, has the economic, logistical or political power to make the change happen and is ultimately responsible for decisions relating to the five W’s (who, when, what, where, why).

A Change Agent.  Typically, but not necessarily, a project director or manager – is responsible to the sponsor(s) for implementing the change. Authority is focused on determining how to deliver according to the sponsors’ mandate and targets’ needs.

A Target is a manager who directs individuals or groups who must actually change the way they think and work for a change to be successful. Targets include managers of departments within the initiating organization but can also include managers who are external to the organization initiating the change, such as customers, vendors, partners and distributors.

A Champion is a manager or senior staff member who enthusiastically supports the planned change and has the power, influence and respect necessary to help bring about the necessary behavioral changes in the managers and staff that are affected by the change.

Decision Framework

I look to PMs to ensure that stakeholders are actively engaged in decision-making and that their deliberations encompass the breadth and depth of the planned change.

For example, the Project Pre-Check Decision Framework addresses four domains: the nature and characteristics of the change itself, the impact on the environment within which the change will be implemented, the assets that will be needed to support the project or impacted by the change and the specific requirements for how the project will be conducted.  

These four domains contain 18 factors and 125 decision areas that can be considered for each and every change. It’s a great starting point for building and monitoring stakeholder cohesion.

Processes

I expect PMs to ensure that stakeholders understand the processes they are using to manage a change and use them diligently from inception to completion. As an example, Project Pre-Check includes three processes to deal with various project stages: Framing, Diagnostic and Oversight.

The Framing process leverages stakeholder commitment at project start-up to agree on expected outcomes, assess impact on each Decision Area, and agree on the contribution various Decision Areas can make to the success of the project.  

The Diagnostic process assesses existing, in-progress projects. It’s perfect for a major change in project scope or direction, changes in key project players (sponsor, change agent or major targets) or simply to take stock of stakeholder involvement and comfort with progress to date.

The Oversight Process controls scope, risk and organizational impact and ensures expected results are delivered on budget and plan. It monitors stakeholder agreement levels on each Decision Area for the duration of the change to facilitate timely, targeted and effective stakeholder decision making.

Conclusion

Yikes! I know lots of stuff. Hopefully you’ll see how it all relates in the next post, where I’ll look at a very successful project called the Interface Initiative. You’ll see ample proof that a great PM is, in fact, the sponsor’s best friend.

In the interim, if you have a project experience, either good or bad, that you’d like to have examined through the Project Pre-Check lens, send me the details and we’ll have a go.

Don’t forget to leave your comments below