Skip to main content

Tag: Project Management

Rescuing A Project, Part Two

For those of you reading this part two of my article on Project Rescue Management: welcome back. For the new readers amongst you: welcome.

After having read part one you may have asked yourself “why would anyone need a project rescue process or an experienced Project Rescue Manager?”.

The question is logical but the following facts will tell you more about the need for such a process and such a type of professionals:

  • When I did a lookup for the words “project problems” on Google, I got a screen showing there are (at least) +23 700 000 pages found; the sheer amount of discussion on problems around project management indicates that some heavy problems exist and a structured approach to solving such problems is needed;
  • When we look at the financial impact on regional economies (e.g. the USA or the EU-region) the estimated financial size of problems around (IT-related) projects gone bad is simply staggering

“One estimate of IT failure rates is between 5% and 15%, which represents a loss of $50 billion to $150 billion per year in the United States. Another study estimated that IT project failures cost the European Union €142 billion in 2004.”
(Source: Gallup (2012)

The estimate given above is based on research from 2004 as you probably read yourself if you looked up the article I am quoting from. And those figures are only the estimated financials. They do not include negative psychological, public/commercial impacts or costs of other types of impacts and their associated monetary value.

This short introduction alone shows you why Project Rescue Management is a thing to be thought about.

It could also be worth thinking about from a commercial aspect. A consultancy organization could for example define a new and very disruptive business line: making projects gone bad right again….

If THAT is not disruptive, I don’t know what else is.

My position is: it needs to be done. How? By orienting ourselves much more on the benefits of what needs to be done or what we should not do and why, a.k.a. Business Case Development and Business Case Management. And making sure that selected projects are – based on their business case – ordered and aligned to company strategy. Strategic alignment to organizational goals alone gives projects a better chance of success (by 54% at least as some research by the PMI stated some time back).

But we need a new type of project managers (and managers) with new skillsets to get this cultural shift started towards Business Case Driven Project and Program Management done (“BCDP^2M”, copyright S. Bals, 2017). I already mentioned some personality traits and characteristics such project managers should have. They will also need new skillsets. Which ones? I take the liberty to quote again from mr. Kerzner’s book “Project Management Metrics, KPI’s and Dashboards” (Publish. John Wiley & Sons, 2013(C), ISBN 978-1-118-52466-4, page 3):

  • Business Analyst Skills or Business Management (*)
  • Program Management (*)
  • Business Processes (*)
  • Managing Complex Projects (*)
  • Six Sigma
  • Risk Management (*)

(*: I actually received some very negative comments about my additional areas of knowledge and experience ; in a job interview some time back I got accused of being “more of a business analyst or business consultant than a project or program manager; but as it turns out, when you look at the shortlist above, those skills are exactly some of the plus-knowledge-packages a good PM or PgM should have nowadays….)

Some other trainings that could be beneficial for PM’s or PgM’s are also described by mr. Kerzner on the same page:

  • Establishing metrics and KPI’s
  • Dashboard design
  • How to perform feasibility studies and cost-benefits analysis
  • Business analysis
  • Business case development
  • How to validate and revalidate project assumptions
  • Establishing project governance
  • Managing multiple stakeholders
  • How to develop coping skills and stress management skills

Note the emphasis on business analysis, process analysis, cost-benefits analysis, business analysis, business case development. I add here that business case management should also be included to the list.

In short: the emphasis lies on the business, it’s processes and a business case for the project (or program) aligned to the strategy of the organization.

That’s also why in project rescue management the business case remains a leading document. THE leading document if you ask me.

Let’s talk some more on how to get on with a project rescue. On the following pages, you will find he first two steps in a six-step process (or nine steps if you prefer to really go step by step, sometimes that’s useful).

0. Initiate

Before we continue I would like to give you a bit of a view of the standard Project Rescue Plan I have grown fond of using.

bals 09182017 1

(Copyright Stephan Bals, not to be used, stored in any form, distributed in any form without authorization of the author)


Advertisement
[widget id=”custom_html-68″]

I use this slide to show this to my potential customer/employer when discussing Project Rescue Management and later during the definition of Project Rescue Mandate. Consider it like a place holder, based upon which you can explain to your potential customer/employer what the different stages are and describe at high level what your customer/employer will get per stage. It’s always handy to show you know what you are talking about.

As you can see in the slide, phase 0 is the Initiation Phase.

During this phase, no mandate for work has been signed yet, expectations have not been made 100% clear. That comes after the Mandate Stage. This is like a “meet and greet”-stage for candidates for the Project Rescue Manager role. It’s is just you as the shortlisted candidate Project Rescue Manager and (a) representative(s) from the company wanting to hire your services having a meeting and discussing on a high level what the problem is during the first meeting. Don’t drill down too deep on the problem(s) yet, you will be doing a lot more of that when you as Project Rescue Manager have obtained your signed Mandate.1

You as the potential Project Rescue Manager and the potential customer are getting to know each other, discuss your cv, discuss work you have done before and possibly you will be asked to share a couple of references your potential customer can check.

A first interview like this – in recent times – most of the time starts via phone-chat with a recruiter. I say “don’t”. If you can, you – as the owner of the troubled project (or program) -should at least meet via Skype of video conferencing but preferably face to face right from the start.

When It comes to meeting that very important person who can possibly help you get your project going again, you as the party looking for that Project Rescue Manager, have a bit of a budget ready for the interview sessions. Like I said, you will preferably want to meet your candidate(s) face to face and they will probably want to see payment for travel costs and possibly one night of hotel costs. And you do not want to look avaricious. Do not be penny wise, pound foolish. Be a good host when inviting your candidates. A well served table builds the biggest smiles and shows appreciation to your guests. First meetings can be short. If you as a potential customer don’t get the right gut feeling about your potential Project Rescue Manager during this short (max. 30mins) talk, thank him/her for her time. If the candidate at the table catches your attention, then talk some more, possibly take them out for a bit of dinner. You as customer/problem owner have little time, but you need to take some time to get to know someone asap.

If you do select some candidates, second talks should be held in more detail on the problems requiring a Project Rescue. Also, the second (and third) round of talks can be held on the same day and with different representatives from your organization. Again, for second and/or third talks, have a bit of a budget ready for all the reasons I already mentioned earlier.

1. Mandate

bals 09182017 2

As part of the final selection process, during interviews you as customer/employer will automatically drill down to one candidate. To get there, like I suggested you will have discussed with the two remaining candidates of your selection process. During your last meet-up, you also define and preferably finalize the mandate for your Project Rescue Manager.

Defining this key artefact together will help you in making clear on how you will work together, what levels of autonomy and what obligations the remaining Project Rescue Manager will have. Your Project Rescue Manager should be able to help you shape his/her mandate coming from experience on this kind of work.

The candidate that gives you the feeling – because that is in the end what any decision is based upon – he/she is working together with you on a well-defined and usable Project Rescue Mandate is the one you will select. Logically.

As a customer, be prepared to talk about things disgustingly honest. Do not act shocked, do not fake false pride. You and your selection board cannot afford it and your Project Rescue Manager cannot afford it. Every day not used well is after all spent burning money for no purpose.

How honest can you expect? Let me give an example of something that happened with one of my clients. I remember one occasion a long time ago, having arrived at the final selection moment, I looked my client in the eye and clearly stated that I wanted the following lines added to the Rescue Mandate: “if any party involved at the decision-making level from your side lies or deliberately gives wrong facts, figures or any other kind of wrong information or bad cooperation I will walk away without having any further contractual or other legally binding obligations to you as my client and this will be the [sum of money] you will pay me without delay if the company is at the cause of my departure coming from not following this agreement”. The gentleman that sat across the table from me blinked, but after a couple of seconds simply said “understood, agreed and so noted in the mandate” and wrote it down.

This gentleman became a friend of mine and still is a good friend of mine now many years later. Was I brutal? Was I – in the eyes of certain readers – possible a bit rude? I do not think so. I wanted to see and feel how this gentleman and the board behind him would react if I gave direct, blunt opinion, feedback, statements or questions.

This gentleman and his board reacted correctly. By giving an honest reply. Would I have stayed if he had said “not acceptable” and he had motivated his reply in an honest way?

Yes. Because my aim was testing the honesty-level. I just wanted to point out (again): being honest in Project Rescue Management will have big paybacks!

During the definition of the Project Rescue Mandate also discuss other items that may be of Interest to your Project Rescue Manager. For example: access to personnel files of team members, access to contracts with suppliers and/or other external 3rd parties and so on. Decide and register in the mandate on these and any other valuable topic that comes to mind what your Project Rescue Manager can/needs/will have access to. Think for example, of the project business case, project status reports, risk reports, board meeting memo’s, the last version of the signed project SOW, number of changes, project assumptions, project quality reviews, test information or any other documents that apply.

Your Project Rescue Manager should be able to give you a list.

Also, as Project Rescue Manager you should have the right to interview anyone involved  in the project, external or internal, high or low, without this having any consequence towards individuals being interviewed.

Also, decide on how many team members your Project Rescue Manager will want to add.

And do not forget to talk on the current status of the project! (frozen, partially frozen, continuing? And why?)

2. Analyze

The customer has selected the Project Rescue Manager and a signed Mandate is now on the table. We move on to stage two. This stage – to my modest opinion – falls in to three subparts.

bals 09182017 3

A. Meet, greet and learn

We can make this bit as long and as difficult as we want, but beauty lies in simplicity and love is fed by honesty and loyalty. So, let us keep things short and sweet here.

Your (s)elected candidate will right from day one need to be announced, introduced to a large number of people and shown around. As to the meeting and greeting part, it is nothing less than professionalism if you from the customer-side have prepared a list of people (with a picture if possible) for your Project Rescue Manager to meet and greet. This could have been prepared during the Project Rescue Manager Selection and Mandate Process. Make someone available to support him/her during the first two weeks, if but a couple of hours a day. I would even go so far as to advise you as the higher-up who hired the Project Rescue Manager that you show him around to key people yourself. It is a good opportunity for you as higher-up to have some face-time with the work floor.

It will also be of interest to have the list of project meetings, locations, persons attending, time & days of week already available including access to project documentation from start to current date, teams, team compositions, phone numbers, email addresses, availability and location and contact information of decision makers, stakeholders, customers, 3rd party contacts, team members, PM’s, line managers, functional managers, et cetera. To name but a few information topics that might come in handy right from the start.

Elements such as having a desk or office space and all the usual stuff as a cell phone and a laptop should also have been taken care of right from the start of course. I always like to have a meeting room available for my use on the job in which at least 8 to 10 people can be present, work, or even have a chat amongst each other when needed and which has working video conferencing and phone in place. Bad Managers would call it a War Room. I hate war rooms. The very word brings an image of negative pressures and bad energies. I prefer to call it a Safe Room. What is said in confidence in this room stays in this room. People need to feel safe in this room.

But back to business. Your Project Rescue Manager will need such a room to be able to read, meet and talk with people, if not but simply think.

B. Analyze

You have decided on the information to be available to the Project Rescue Manager. Now make that information available.

I for example want to understand the following:

  • what is the customer company culture and what is/are the cultures in 3rd parties involved?
  • Was the plan and number of deliverables, PBS, WBS, capacities, benefits unrealistic/overestimated, meaning: did the project have to deliver too much in too short an amount of time? Why?
  • Was this project of personal or political importance to someone or did the whole organization stand to benefit from this project?
  • If any external parties are involved, how is the relation between customer and 3rd party/parties? and why? Duration of that relation?
  • from a business case perspective, what is purpose of the project, what departments or division(s) will it influence, what products, capacities, benefits in support of what capacities, products, services will it deliver to meet desired strategic outcomes, and is the business case still valid, do we need to adjust deliverables and outcomes, or do we simply need to scrap it?
  • what performance indicators have been selected, used for this project and why?
  • was/is benefits management in place and does it play an active part in the project?
  • how has the project been doing up to now?
  • was there a process for change control and a CAB (Change Advisory Board)?
  • was the CAB also responsible for OCM (Organizational Change Management) activities that where related to the project?
  • What was the level of autonomy of the CAB?
  • was there a Customer Involvement (sub-)plan of what activities customer representatives will be involved with, when, how many, locations, levels and number of supports from the project team (or a separate sub-project team), trainings, purpose, group descriptions and roles attending, et cetera? If no, why? If yes, where is this (sub-)plan? Who owns it and drives it (from supplier and/or internal to the customer)?
  • Have we received all weekly, monthly. half year reports and/or deep dive reports?
  • what problems have arisen on the project on the whole and what actions have taken to solve these problems up to now? (to be asked at different levels to capture different views)
  • having a good look at RAID-logs, who owns what, what was done, when was it done, what where the effects of what was done?
  • was the Project Board involved, supporting or just bullying (honesty ….. but it does happen)
  • how many change requests came, how many where approved/denied/why, scope/time/cost?, how many times was the project base line and project budget adjusted?
  • how many team member changes happened, how many Project Board member changes happened, how many times was the project manager changed, and why?
  • do stakeholders still believe and support the project? If yes, why? If not, why?
  • how is the project team structure organized? Partially onsite, some nearshore, some offshore? How many team changes (members, team size, et cetera) happened per location? And why?
  • Are there any corporate directives on cost reductions on our side or third party side that influenced the project? And why did such directives come in to view?
  • In what phase is the project currently? Is anything being worked on or is it in “full freeze”? And why?
  • What are the performance indicators used?, who selected them and why?
  • what was the workload per team member? And per team? How much overtime did team members put in and the team overall?
  • How were team members treated? (internal and external team members alike)
  • How regular was overwork for (certain) team members?
  • How are team members holding up? (happy, unhappy? why?)
  • How where business/customer project team members treated? Why?
  • Has the difference in “people-management-approach” per type of team led to additional annoyances? Why?
  • How is risk management set up?
  • is there a PMO involved or not? what is the role of the PMO and its level of support and influence?
  • what is the project complexity and why?
  • what is the level of commercial/political/strategic need for this project in the organization and why? (it’s a good question to ask certain decision makers and stakeholders besides getting answers to this one from revisiting the business case)
  • What was the level of autonomy of the Project Manager(s)? (or Program Manager(s))
  • what type of project management methodology(-ies) was used? Why?
  • How did people (customer, supplier, others) react to working within this(/these) type(/s) of project management methodology?
  • Would another type of project management methodology (or (mix of) methodologies) have been better suited for this project and why?
  • How where Project (or Program) Manager(s) treated? (as equals, as “simply do what you are told”, as valued colleagues who were also consulted on problems, issues, risks, improvements on how to do things better?)
  • …….

You could decide to split up these questions in certain categories. I do. For sure you will not ask these questions to everyone. For example: a Project Board member may not be asked all the questions a project team member will be asked. I divide my questions in to categories, but I take the liberty of not showing you an example of such here, since you may have your own lists.

I will tell you my favored way of getting the answers to most of these questions. In some cases, it’s just getting hold of the numbers and/or documents. But on people matters, it’s always best to do a representative number of one on one interviews. The Safe Room where the Project Rescue Manager works is probably the best place. People can talk in safety, away from prying eyes and ears or interruptions from others.

As to the above displayed list of questions, and some of them might sound double, these are but a handful of questions I (and my team members, when I appoint more people depending on the sizing of the work at hand) need answers to. I actually have quite a list that I like to go through. This is information. Based upon information I can build a picture of the project as it came to be, started, had its lifecycle up to this moment where I appeared and if the project still has a valid business case after having been reanalyzed itself, what possible trade-offs that need to be negotiated and what chances such possible trade-offs have of being accepted or not.

This is a lot of work that needs to be done in a short time. It is especially a lot of work for one person. Which again is why your Project Rescue Manager will need all the support he/she asks for (including the budget and the autonomy to install an assisting team to the Project Rescue Manager when called for), especially the cooperation coming from you as the customer.

C. The First Draft Rescue Plan

During this Second phase (that should last no longer than one to a maximum of four weeks (depending on the size and complexity of the project it could take twice as long), he/she (and his/her selected team) will take in all this information made available per the mandate (and maybe more) and your Project Rescue Manager should also build and present a Draft Rescue Approach Plan that will last up to the GO-stage. At least after two weeks it should be clear what parts of the project or even the project on the whole should be frozen, continued, partially continued for now.

But as to the first draft Rescue Approach Plan, like I said before, I usually use my time-line slide and build on that. But the Rescue Approach Plan needs to be built in more detail. In four weeks’ time at the most (again depending on the size and complexity of the project), it should at least have a clear definition of the Analyze, Initial Report, Evaluate/Adjust/Agree and Go stages, things required per stage (types of information and/or actions) and deliverables (from the Project Rescue Manager, project team, decision makers, customers, suppliers or other teams). People that need to deliver part(s) of the Rescue Project Plan should be held to their obligation without delay or excuse. The Project Rescue Manager will also have drafts of the Rescue RAID Log, Communications Plan, Team groupings and activities, and a draft financial plan up to the Go-Stage.

One should also have revisited the Business Case for the project during the first two weeks and a report on the status of the Business case should coincide with the delivery of the first Project Rescue Report. More about this later.

It is also imperative this stage to formally(!) decide on a Project Rescue Board. Your Project Rescue Manager may not have all the information yet to choose the best formation, so some blanks are logical. But during working between Project Rescue Manager and customer, names & roles & responsibilities must become visible. Fill in the blanks during the Analyze stage. Your Project Board may or may not contain members of the original project board. Remember: you are in a rescue situation. Other influencers and/or decision makers might be beneficial to the project being rescued. Why? Because simply speaking, there are gatherers and there are hunters and there are protectors.… I’m sure you understand the difference.

But you will need a Project Rescue Board with the right people on board. Project Rescue Management is not something you do alone. It is also never about doing a bit more of the same thing with the same people in the same way that got your project in the mess it is in.
You will need people with power in the right places to help you out. It is just simply so that at the same time when considering this, you also need to consider that the people on the “old” project board might not be the right people to be involved in the rescue.

For now we have arrived at the end of part two.

I will show you more steps in the process in part three of this article, coming soon.

As before, if you have remarks, suggestions, or need help on a project rescue, you can reach me at [email protected].

1 Please remember for later: no Mandate, no work! If the customer says they have selected you, make them write an email to you confirming that on the spot, containing price, a timeline and a “breach of contract” set of rules. If you are experienced in this game, you can bring your standard terms to the table for quicker discussion

Why People Fail the PMP® Exam

Failing the PMP® Exam is a negative experience, which I would not wish upon anyone.

After teaching PMP® Prep for nearly 10 years, there is nothing more rewarding than receiving an email from a student, saying, “thank you; I passed the exam”. Unfortunately, occasionally a learner will reach out to say that they didn’t pass the exam.

Fortunately, this is a very rare occurrence. However, when this does happen, it is as devastating for me as it is for the learner, and a part of me says, “what did I do wrong? Is it the material I used? Was my instruction method flawed?”.

I have taught thousands of students, and after some substantial thought and data analysis I have concluded the following five reasons as to why someone may fail the exam:

1) Lack of Preparation:

It is strongly recommended that a learner scores at least 85% on a full-size practice PMP exam. Many learners take short pop quizzes composed of 20-50 questions, score well on those, and then determine that they are ready to write the PMP exam; this is not the case.

Solution: Other than the obvious (preparation), do as many questions as it takes to get you to the 85% threshold.


Advertisement
[widget id=”custom_html-68″]

2) Difficult Exam:

PMP® Exams are random; some are easier; others are more difficult. Also, different exams have a different focus. Some exams focus more on change management; others on mathematical calculations or procurement. Depending on your familiarity with a knowledge area this could be one reason for failure.

Solution: Eliminate the possibility of having a “weak” knowledge area by mastering all knowledge areas.

3) Turning the PMP® Exam into an Earned Value Management (EVM) Exam:

Let’s be honest; math can be challenging for some PMP® candidates. This is quite understandable if you don’t work in a field which requires you to crunch numbers on a regular basis. Some learners devote an unnecessarily large amount of time to memorizing the EVM formulas.

Solution: Don’t spent any more than 10% of your study time on memorizing EVM formulas.

4) Inadequate/no Brain Dump:

Brain dumps usually include EVM formulas, profit forecast calculations, and contract types. Most PMP® trainers recommend that students memorize various formulas and factoids, and write them out in the exam room prior to starting the exam. Writing out the brain dump is essential as it relieves the pressure from focusing on memorization and allows the candidate to focus on the PMP® questions instead.

Solution: Access a well-developed brain dump from a reputable trainer.

5) Second-guessing Yourself:

Frequent second-guessing of your final answer on the PMP® Exam is either an indication of having insufficient knowledge or sheer hesitation caused by stress. Waddling between two answers is frustrating and a bad use of time.

Solution: If knowledge of exam content is not an issue, choose the answer which strikes you as being the most likely at the first instance. If knowledge is the issue, you are not ready to be writing the PMP® exam, and consider doing more practice questions.

5 Dimensions – Meaningful Measures of Project Manager Success

Projects should be measured on five specific dimensions: efficiency, customer, business-now, business-future, and team success.

From these dimensions, business measures, customer measures, and process measures should form the basis for creating various metrics to measure the project manager. I say “various metrics,” because there simply is no single set of measures that universally applies to all industries and all environments in which companies compete.

We understand success means different things to different people, in different settings, and at different times. To create meaningful measures to evaluate a project manager’s success, consider first the position’s connection to organizational success. From an organizational perspective, success is multidimensional as well. A healthy organization will have a mix of immediate goals, mid-term goals, and long-term goals. These goals and their underlying success metrics should be the origination point for evaluating a project manager’s success.

An organization’s immediate goals are efficiency related, focused on getting the job done and on operational excellence. Immediate goals deal with the project’s constraints and evaluate from a quantitative perspective, whether the project delivery was within required scope, budget and schedule.

kay 09062017aMid-term goals are completion and satisfaction related. This dimension relates to the customer and examines success not only from an efficiency standpoint (i.e. milestones met), but also adds an effectiveness perspective; for example, success of the end-result. Did we solve the customer’s problem and meet functional performance and technical specifications? Did we achieve through the project the benefits they hoped to achieve? Is the customer satisfied and are they using the product/service delivered?

While mid-term goals focus on the customer (important to any organization), business-near and business-future dimensions examine corporate (or enterprise) success and strive to evaluate the efficiency and effectiveness of a project, specifically, the short- and long-range impact to the performing organization.

The business-near dimension (a long-term goal relatively speaking), examines short-term business results to measure commercial success using return on investment, net present value, internal rate of return, payback, and contribution to free cash flow.


Advertisement
[widget id=”custom_html-68″]

Business-future evaluates the longer-term benefits delivered that prepare the organization for the future. These are projects initiated for wider reasons than just immediate profits. For example, beyond ROI are such things as visibility, publicity, corporate reputation, and customer value. This dimension also scrutinizes success to analyze and determine if the organization is in a better position to insure its survivability and competitiveness well into the future. Examined is a whole host of factors, which may include (but are not limited to), have we opened new markets, developed new or not yet existent technology, increased capabilities, gained technological superiority, increased barriers to entry for competitors, or developed a new generation of products to exploit?

The team dimension seeks to measure (from an efficiency perspective) the unique micro-culture surrounding the team. Qualitative measures gathered from within this dimension are important to organizations, as teamwork effectiveness has a clear and visible connection to bottom-line results.kay 09062017b

Many of these soft measures provide useful insights into the leadership qualities of the project manager and need to be included when measuring the project manager’s success.

Such measures often point directly to a project manager’s emotional intelligence, values, character traits, leadership qualities and the ability to use personal influence (soft skills) to lead people. The sum of these skillfully applied leadership attributes can draw forth the full team potential and create a fun and spirited work environment, while producing change and movement that get results.

kay 09062017cThe Team Dimension is about Leadership. Don’t forget the soft measures. Business is about people and relationships …end of story; it’s how business gets done. Take care of your people; success (and profits) will follow. 

Measures useful in gauging teamwork effective-ness may include discussion or metrics pertaining to information sharing, involvement of the customer, excitement, conflict management, emotional energy, collaboration, project team satisfaction, and a host of other soft measures.

Achievement of these goals, often structured and achieved through projects, will if executed correctly, create economic value and competitive advantage; these being (primarily) the sole reason a for-profit organization exists. The individual carrying great responsibility for the attainment of these collective goals is none other than the project manager.

The ability of the project manager to deliver on all these levels should form the basis from which his or her success is measured. His or her actions, given the right setting and/or right circumstances can make or break a company, while skillful execution can bring great success to an organization.

Obviously, a project manager shoulders tremendous responsibility. The best project manager(s), as measured against these critical success dimensions, should be the one(s) that rise to the top to lead the most important projects.

A project manager (acting in a principal-agent capacity) is charged with project execution accountability, but has an even higher fiduciary responsibility to create economic value and competitive advantage. In a perfect world, these dimensions determine how a project manager’s success is measured.

If all the above is important to the employer, as they would readily argue they are, why then would a project manager not be measured or held accountable on the totality of efficiency, customer, business-now, business-future, and team-related metrics? Often easier said than achieved.

Ways Cloud Based Project Management Software Saves Time And Money

Cloud Technology – it’s the new buzzword and is taking the entire business world on a new dynamic exploratory track!

The early adopters have given the verdict – this technology is radical and groundbreaking. It surely has the power to fast track any organization onto the pathway to success. From small and mid-sized firms to large multinational organizations, cloud technology is completely revolutionizing the traditional workplace. Cloud-based project management software solutions are one arena that all companies are rapidly investing in and are reaping huge benefits. So just how can your company save loads of time and money by using a cloud management software tool? Let’s see the key benefits:

  • Round The Clock Access – Cloud based project management software provide instantaneous access to content and project plans from anywhere in the globe at the click of a button! All one needs is a high speed internet connection and the cloud interface can be accessed through a variety of devices such as mobiles, tablets, personal computers or laptops. So remote teams can be scattered all over different geographical work locations and still access an updated version of the work plan and collaborate on projects in real time. Cloud based project apps create a central workspace accessible from anywhere, so various teams can communicate seamlessly. It keeps members up-to-date about the various facets of project management- document sharing, versioning, labeling, email notification, alerts, email based collaboration, comments, discussion forums and meeting notifications. This round the clock accessibility saves companies precious man hours and money, and also increases productivity exponentially.
  • High Level of Safety and Security – Data security is a major concern for most managers as they do not want sensitive and confidential business data to reach into wrong hands. However, cloud-based software applications are highly reliable and secure, having strong safeguard mechanisms to protect customers’ data while in-transfer and at-rest. There is no danger of data loss or theft through being intercepted in transfer due to the high grade encryption that is used by most cloud based project management solutions. Good cloud project management software incorporate first-rate security features, using highly protected data centers, daily backups and servers with internal built-in disaster recovery. So these wonder solutions save a company lot of time and the hassle of worrying about recovering lost data!

  • Advertisement
    [widget id=”custom_html-68″]

  • Better Organization and Reduced Dependency on Email – Cloud based project software are indeed a great way to manage huge volumes of critical project information in an organized and orderly manner. Managers do not need to scroll down huge unending e-mail chains, as all required updated information is available in a flash! Providing quick and easy visibility to common documents can greatly increase efficiency by eliminating redundant e-mail dependency and knocking down barriers to access. Teams can make changes and updates as they occur and revise schedules in real time to provide an accurate and holistic view of impending projects. Cloud project applications create a lean and flexible work environment, thus massively enhancing client collaboration and productivity levels.
  • Cost Efficiency – A study has revealed that a whopping 82% companies agree that switching to cloud technology has saved them money and increased their bottom line profits. Most cloud based project management software’s are highly customizable with differential pricing plans, thus enabling organizations to go in for modules according to their business requirements. Cloud based project management servers dramatically reduce costs and the up-front investment is usually a fraction of what businesses might pay for a full time software license. In fact, cloud based tools do not require any expensive hardware setup; neither do they require any complicated installation. All one needs to jump on this bandwagon is an internet connection and a device! Hence, huge savings on software expensive is one of the biggest benefits that a company may gain from adopting this innovative technology.
  • No Time Consuming Software Updates – Cloud platforms are great tools for preventing those lengthy software updates which always seems to appear during ultra-important business. As soon as new features are available, users gain instant access thus eliminating the need for tedious time consuming updates. Cloud based project management interfaces allow for automatic integration with a variety of business tools, enhancing flexibility and ease of implementation. It offers diverse functional teams with a host of collaboration features (e.g., commenting, document sharing) that create a more efficient and productive process. Another major benefit of cloud project management systems is rapid scalability— it aids the addition of new users and features when a team grows or business needs change. It is hence the perfect business solution which can propel any company to gain a huge competitive edge in the market.

In today’s vigorously changing business environment, the cloud based technological revolution is undeniably the key to success. It is the perfect accessory that enables remote teams to work together, communicate and collaborate to achieve business goals. Cloud technology is now indeed a prerequisite for organizational accomplishment and truly leads to tremendous positive business transformation!

When a Project Dies

Despite our best efforts, sometimes projects just die.

Projects die for different reasons – a new stakeholder comes in with a new vision, the stakeholder cancels the project because he or she realizes what they wanted could be done within current applications – there can be a myriad of different reasons.

This week, a project of mine died. Initially, I wasn’t sure how I felt. This had been a very challenging, long, drawn out project. We met weekly with the stakeholder and her staff almost every week for over a year. I have two over-stuffed manila folders of notes I had taken during meetings.

Let me be clear that we are new to the business analyst world and still working on our overall process, so while that timeline may seem unreasonable, the stakeholder was fine with it. The project was completed once, when the stakeholder and her staff met directly with the developers, who started planning the application in their heads during the first meeting. The final product wasn’t up to par and therefore, was never released to the end customers. The stakeholder wanted it done correctly this time and was willing to wait as long as necessary to achieve that desire.

The stakeholder brought her own challenges to the table. She would often change what their process was while other members of her staff would question the changes. They didn’t understand how to use computers all that well and I suspected a few of the “problems” with the initial application were merely user error.


Advertisement
[widget id=”custom_html-68″]

But, it was my job to complete this project to the best of my abilities and offer them an application they could use.

I created the SIPOC and As-Is and To-Be process maps while user requirements were edited again and again as the meetings went on. During the project, our area decided to switch from the waterfall to the agile methodology to prevent year-long projects with no results. I developed user stories and learned information I hadn’t learned during the year-long meetings.

As a business analyst, I felt finally ready to hand the information over to the technical team. Unfortunately, several personnel changes left us with few developers to work on the project. Ah, the best laid plans of mice and men…

Still, time wasn’t of essence as the stakeholder and one of her staff members were out this summer on extended leave.

Then, last week, I learned the stakeholder’s area has been disbanded after review by a new director and just like that, the project was over with little fanfare.

While part of me was elated – this seemed to be the never-ended project – another part of me was mournful. I had invested quite a bit of time and gone through a huge learning process with this project, only to have it never see the light of day. Part of me wanted to say, “Yes, yes, it is finally done and it is beautiful,” to the naysayers in our area that said the stakeholder wanted too much, was unreasonable, and the project itself was unnecessary.

I had also developed a friendship with the stakeholder and her staff. We’d exchange pleasantries before and after meetings and learned a little about each other. Now, everyone had been laid off and as painful as the project was at times, I wish they hadn’t been.

There are plenty of other projects on the horizon, but I’ll always remember this one as the project that helped me grow and taught me a lot of lessons.