Skip to main content

Tag: Technical Project Management

3 Most Common Mistakes to Avoid in Managing Multiple Projects

Ever found yourself in a state where you are managing multiple projects? If you compare your situation today from about three to five years ago, the chances are that you will see more projects on your plate that need to get done.

A project can be anything, from designing a coffee machine for your client to remodeling their workspaces or even to studying ocean currents. The bottom line is that project management is an integral part of every business today. And, when you are handling multiple projects, it means more than just dealing with multiple project schedules. With multiple projects come in multiple teams, multiple stakeholders, multiple scopes, multiple change requests, multiple budgets, multiple issues, and risks, even possibly multiple clients. All of this becomes an entirely different ball game and managing it may seem a tough nut to crack, even for the most seasoned project and program managers. Even though you may already be using a project management software, you must always steer clear of these three common mistakes that could affect and potentially jeopardize your projects.

Not Setting Project Goals Upfront

Projects, by definition, are meant to achieve specific goals and objectives. By defining clear and precise goals and objectives for your projects, your teams can focus solely on those goals and outcomes. If the goals are unclear, it can quickly turn your formal project management process into an uncontrollable juggernaut of chaos coming in the form of scope creep, unrealistic expectations from stakeholders, dried up cash flows and all that jazz. Goal setting is a vital component for projects’ success. Yet, when multiple projects come in, managers often seem to take a shortcut and overlook this crucial process of goal setting that can potentially prevent and solve so many problems down the line. Setting project goals upfront help you in the following areas:

  • Understanding why you are doing this project and aligning it to business strategy and plan.
  • Understanding the deliverables that the management or client is expecting from the project.
  • Establishing clear criteria for success (or failure).
  • Identifying conflicting objectives, outcomes or expectations from multiple projects.
  • Identifying resources and capabilities at the beginning.

Asking the right questions at the onset of a project will help you identify meaningful project goals and objectives, which in turn help manage multiple projects successfully.


Advertisement
[widget id=”custom_html-68″]

Not Prioritizing Projects

Manage your priorities, not your time. This quote frequently appears in many productivity and time management blogs. One of the most commonly heard complaints from project managers is that they are struggling with deadlines. The reason being too many times we see teams working on a project that is a lower priority while a higher visibility project starts to slip. This happens when project priorities are not clearly communicated to all stakeholders. When you are managing multiple projects, you often have cross-functional teams working on several tasks across these projects at the same time. If you don’t know what your priorities are, you will end up spending their precious time on useless activities causing important milestones to be missed and deadlines not be met. According to the Pareto Principle, 20% of a project’s input is responsible for 80% of its results. Use this principle as a way to prioritize your efforts. The art of prioritization comes a long way in gaining clarity about which tasks should be assigned to whom thereby help save a lot of hassle and headache.

Forgetting that it’s all about People Management

We live in a world which is increasingly being driven by automation, tools, and data. With organizations investing in advanced project management tools and globalization driving a need for collaboration, the people side of project management does tend to get ignored more often than not. Often while managing multiple projects, project managers tend to get bogged down by the scope, costs, quality, and timelines, and forget about the people who are actually doing the work. This results in either failing to properly manage your team members, or worst, micromanaging them. While it may be tempting to control as many things as possible or trying to do everything yourself, it is actually bad for your team’s morale. Project management is all about people management first. It is the people who help deliver on your project objectives and outcomes. An efficient project manager is, therefore, an enabler. Communication becomes even more crucial while managing multiple projects. You need to make sure that you clearly communicate the roles and responsibilities, and everyone understands how and why their part is vital to the success of the projects and also schedule time for periodic check-ins.

Though managing multiple projects may scare you off at first, you can easily overcome it by avoiding these common mistakes and steering your projects to success.

What it Takes to be an Effective Project Manager

Earlier in the year, I worked on a turnaround project that needed some additional project management discipline and rigor.

One of my key responsibilities was to work with the existing project managers to help build up their skills, tools, and expertise with managing creative teams. After the initial discovery and mentoring sessions, I generated some guidance to help them focus on becoming more effective project managers.

  • Empathy and listening is key to being a successful project manager. Ask your team members “Where can I help?” and then listen to them. They will tell you where they could use help or are having issues. Helping your teams work through roadblocks is one the most important ways to demonstrate your value within your organization.
  • Be an escalation point for your teams. One of our key roles as project managers is to ensure that open action items and concerns of your team members are being addressed in a timely manner. Related to this is being accessible to your teams. If you appear too busy or unapproachable, your team members will not escalate to you in a timely manner.
  • Teams do not communicate well. It is our job to ensure that any miscommunication or delay in communication are dealt with and “beaten down” in a timely manner. If you are good at communication and promoting collaboration, you will go a long way as a project manager in your career.

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

  • Get your hands dirty. On every project that I have worked on, there is a lot of important work that no one team is assigned to do, yet it needs to be done for the project to be successful. Examples of this are “herding cats”, action item follow-up, procuring additional software or resources, generating drafts of documents for the team to react to, etc.
  • Think strategically and take the time to think about the bigger picture. Someone needs to help guide and focus the team on “The Goal”. Team members rely on project managers to think about the bigger picture and help align them
  • Keep a watchful eye on dependencies and their impacts on milestones. Successful project managers do not track all project activities, but rather, they focus on the key
  • Stay focused on the Top 3-4 critical issues that could delay or derail the team’s progress.
  • Make sure the team takes time to prepare for key stakeholder meetings. No matter how ready someone says they are for a key meeting, you should require your team members to conduct “dry runs” of the presentation content. At minimum, the presentation materials should be reviewed and proofread prior to sharing with stakeholders.
  • Shield the team from as much administrative work as possible. It is our jobs as project managers to keep our teams focused on the most valuable tasks and where they can be most productive.

In summary, effective project managers need to extend their expertise beyond the tools, processes, and mechanics of project management and embrace “human-centric” behaviors.

Never Make the Project About the Technology

Is that cutting edge Cybersecurity technology making your CSO drool and ready to pay boo coos of internal dollars on a bleeding edge tech project to showcase at the next user conference or Black Hat digital security convention?

Is that latest platform recently available to showcase your web apps on recently available and ready for you to use?

Making a project come to life because of the technology that an executive wants to try or wants to say that his division is using is a bad reason to have a project. And I feel it goes against some sort of unwritten code of ethics for project managers but I will get to that in another article, most likely (these ideas have to come from somewhere).

Here’s my take… never ever ever ever make the project about the technology. It can be awesome. And it can be disastrous. You can end up being in the latest tech magazine and your stock may soar. Or you may end up on the heaping pile of Ryan Leaf NFL busts in terms of tech failures. You may find that bust lands you with a headline on CNN about a tech startup losing a billion dollars on a failed project to implement a new security solution that ended up in security breeches, identity theft and lawsuits because your tech team wasn’t quite ready to handle such a project. But then again, they say “there is no such thing as bad publicity” – there is always tomorrow to fix it or capitalize on it. Unless of course this bad decision put you out of business. Then there is no tomorrow.

So what do you do when it appears that the customer or your senior management wants to jump in head first because of the technology? For me, it comes down to these three things…

The end does not justify the means.

Getting there isn’t really half the battle. Getting there successfully with the right solution is the whole battle – the whole project. There is no half battle or partial project. It’s all or nothing. It’s not about the right process or the coolest technology or the headlines… good or bad. It’s about the successful solution. I had one organization I was leading a project for where the client company was so excited about our solution we were implementing – the first of it’s kind in their industry – that they went ahead and published go-live dates in a major industry publication under assumptions made with and by the account manager in our organization who sold them the project.

Unfortunately, those dates became the hard and fast – or “drop dead” – deliverable and implementation dates that I had to build my project schedule backwards from in order to complete and meet the deadlines. There were no other options and no option for me to put together the realistic schedule that I knew and my team knew we could meet safely and accurately. What happened? My team and I found ourselves working onsite at the customer location for two weeks just before Christmas working through issues to get to go-live on time. Blew through money (beyond budget) faster than Usain Bolt can run 100 meters, but we made it!


Advertisement
[widget id=”custom_html-68″]

The desired technology may not be right.

The obvious problem is that the desired technology – this bleeding edge choice for the solution – may not be the right technology. The project team needs to understand business processes, what the “as is” environment is and what the desired “to be” environment should look like and figure out if the customer’s perception of the project is the true need or if the project is bigger (or smaller) and the customer request or need is merely a symptom of the real project. Then, and only then, can the project team step back and formulate the real project. Following that, they can – with the customer’s input – identify what a technical solution should look like including what the proper technology to implement really is. Still hopefully a cool one, but it may not be what the customer is hoping for. “Backing into” the solution from the technology is the wrong way to go… it’s like reading English from right to left… pretty painful… bad outcome… headaches.

The skill set may not be there.

Finally, the team may not have the skill set to implement the desired technology. That doesn’t mean it can’t be done. But it probably can’t be done without a change order to get the right resource or resources onboard – at least temporarily and probably expensively – for this specific project. Don’t get me wrong, implementing a bleeding edge technology in any industry for the first time is feather in the cap of the delivery organization as well as a gem on the resume of the project manager, the business analyst and the entire project technical team. Win-win-win. And the customer organization comes out looking great, too. So if they want it, and it’s the right technology for the project team and the customer is willing to pay for it – or your organization can see the benefits of the end publicity – then go for it. The return on investment (ROI) for all involved to eat some costs will be high.

Summary / call for input

The project is the project. That’s what the team needs to focus on. It’s like putting blinders on because sometimes the customer or senior management will interject their needs and desires and those may be in direct contrast to what is best for them and for the project – and they don’t realize it. Stay focused on the successful end solution while taking all these suggestions along the way, but resist the urge to act upon them. At least not until you’ve ensured that they are the best roadmap to success.

Readers – have you had customer project scenario where it was all about the technology and the success of a new solution? How did you calm the enthusiasm while you sorted through the need to determine if that was the best path for the project. You can just proceed with the customer request as is, but if you get to the end and implement something that doesn’t really solve the need, the onus is on the delivery team, not the customer.

7 Big Tech Project Advances We Should See in Our Lifetime

We are making major technological advances every year…every month…every day even. Some affect just a few of us while some have a lasting effect on a large portion of the population.

Looking at needs from my work and consulting perspective, there are always some “nice to haves” out there think I think should eventually be in place to make our lives, careers, and project successes better and more frequent. What’s on your list? Please read mine – these seven for now… and probably later – and share your thoughts and lists…

I call this one the Tupac.

Holographic imaging should be huge over the next 5-10 years. If it isn’t, then someone is doing something wrong. I cover this in my 3D Project Management topics, but at its basic level we should be able to conduct interactive meetings and conferences without flying across the country to meet face to face. And I’m not just talking about a head image in a box. I’m talking about project meetings where everyone is sitting at the same table and also using whiteboards or whatever in full body presence. If Tupac can perform posthumously at the huge Coachella music festival as a holograph and dance and sing then I would like to think we can figure out a way to put 10 bodies in one room from 7 different locations and save all the airline, hotel, cab and meal costs. Millions in savings every year and possibly a few lives not having your CEO on a plane when it falls from the sky.

Using AI to deliver projects.

In a recent article I wrote for Project Times entitled “AI is Saving Lives – Surely it Can Save a Project” I explained that AI was being used on 911 caller to detect of the callers were experiencing cardiac arrest. AI was detecting cardiac arrest with a 22% greater accuracy than human dispatchers so yes, I figured that sooner or later it would be cost affective and very possible to use AI on projects. How? I’m not sure. I think AI will be a huge factor in project decision making and project progress and status reporting in the future. I’d love to be part of any analysis, research, planning, and testing for this if at all possible so if anyone out there has the time, interest and money to take this on, please include me!

Automated status reports.

Doing things manually in the future will be far less common, and I believe that our project tracking tools will continue to move toward overall automated project status and progress reporting. Generating sophisticated project status reports from all-inclusive tools that do a great job of resource, budget, task, issue and change order tracking should be easy – even providing nice green, yellow and red light high level dashboard summary level reporting for the busy on the go executives you want to keep informed but who aren’t usually going to read all the details.


Advertisement
[widget id=”custom_html-68″]

Something better than waterfall and agile.

In a perfect world, in my opinion, waterfall project management and software development are still the best. If things go off without a hitch, then waterfall should be the best. But we all know project issues arise, change orders happen, requirements change, and technology is harder to implement than we are led to believe… so agile often ends up being the better course of action. I believe that in the future, another option will come about making requirements more solid and some aspects of the PM and development more automated, thus essentially superceeding either of these methods of project and solution deliver.

Walk in walk out.

This is happening with Amazon and a few other places. You have a store, you walk in, take what you want and walk out and you are charged automatically. Great idea to make the shopping experience easier and faster. I’m sure there are glitches to be worked out still, but I could also see some project management applications and tech project development applications. For example, meetings could benefit from some of this technology. The attendance, statuses, decision outcomes, and followup notes could be automated and go out to the proper stakeholders and back to the project manager through automated methods.

I’ve already worked closely with a tech conference software provider that captures badge information, qualifies leads and connects them with the right conference and product materials and the right sales person / account manager in a particular organization (like a conference vendor’s booth) just from the badge scan that happens to all of us when we go to any tech conference like CES, Interop, Black Hat, etc. This technology is cool and ahead of its time right now, but things like this will be – or at least should be – common place in the future.

No hacking.

I’ve always said that hackers are one step ahead of us. If you haven’t been hit, it’s only because you aren’t on their radar yet or you don’t have what they want. Because if they want to hack you, they could right now. At some point, I think we can not only say we are mitigating the effects of hacking or planning for the risk of hacking but that we also have fool proof ways of avoiding the hacking. We aren’t there yet – Tesla proved that for all of us. If Elon Musk – founder of Tesla and SpaceX among other things – hasn’t managed to assemble a team to void hacking, then we aren’t there yet. He professed to have developed unhackable automobile computers only to be proven wrong at the next Black Hat conference within the year. But I believe we will get there… eventually.

Automated test reporting and results.

What about automated test reporting? Is it important? Automated test reporting is becoming more and more important to project managers and certain project stakeholders. It is important for project managers to ensure this sort of reporting is available for their projects and it can help project managers manage tasks better and deliver a project on time with costs under control. There are software applications out there right now and PM service providers along side and behind that software offering this kind of service. I think in the future it will be considered an essential and readily available piece of the project management puzzle.

Summary / call for input

I realize this is just seven. I’ll probably think of four more before I go to bed at night. It’s fun to predict and report on developing trends. My thought is – if you can dream it and if it seems useful – then someone will eventually create something like it to make information better, life easier projects more successful. What are your thoughts on this list? Do you have some of your own to add? Please share and discuss.

OUTSIDE THE BOX Forum: Is CMMI Relevant for Complex Projects

For several years now the SEI Capability Maturity Model has been widely heralded as the ideal descriptor of the state of project management maturity in the contemporary organization.

Level 3: Documented Process that Everyone Uses has been the goal for all to achieve. At that Level projects can be effectively executed and managed to produce the expected business value that justified them in the first place. That may be true but its adoption statistics are disappointing. Mark Mullaly reports [Mullaly, 2017] that less than 2% of organizations have reached Level 3 or beyond. Based on Mullaly’s data most organizations operate at Levels 1 and 2 – i.e., project management processes and practices border on a free for all with project success totally dependent on the expertise and management preferences of the project manager and the team. At best that borders on organized chaos and creates obstacles to senior management’s ability to effectively control project portfolio investment decisions.

So, faced with the preponderance of Maturity Level 1 and 2 organizations how could CMMI adapt in order to maintain its relevance to Hybrid Project Management? This article answers that question.

THE COMPLEX PROJECT MANAGEMENT STATE

The complex project management landscape defines the types of projects that have challenged the project management community for nearly 30 years because the commercially available Project Management Life Cycle (PMLC) models do not align well with the constraints placed on these projects:

  • the physical and behavioral characteristics of the project
  • the cultural and organizational environment in which the project will be executed
  • the changing market situation where the deliverables will compete

That lack of fit between the PMLC model and the project is reflected in 2/3 of the projects having failed or challenged. Hybrid Project Management has been below the radar for years. It is a fact of life and the Capability Maturity Model Integrated (CMMI) has not yet responded.

THE DESIRED END STATE

The desired end state in a Hybrid Project Management (HPMgt) environment includes a vetted portfolio of tools, templates and processes that can be used by a Hybrid Project Manager (HPMgr) to design and maintain the alignment of a dynamic project management approach to a specific project based on the three constraints.

The success criteria for complex projects is the attainment of the expected business value that justified the approval of and resources to support the project. That success criteria will be one or more of the following metrics:

  • Increased Revenue (IR)
  • Avoidance of Cost (AC)
  • Improved Service (IS)

The criteria are defined by the well-known acronym IRACIS.

The complex project landscape was not defined nor understood when the Capability Maturity Management Integration (CMMI) was introduced. That raises the question of its applicability to HPMgt and effective use to the HPMgr.


Advertisement
[widget id=”custom_html-68″]

CMMI Maturity Level Definitions for Hybrid Project Management

The Software Engineering Institute (SEI) at Carnegie Mellon University introduced the Capability Maturity Model (CMM) in 1987 and the CMMI in 2002. It has become the de facto standard for measuring maturity of processes and the practice of those processes.

Maturity Level 1: Ad Hoc or Informal

Basically, everyone is managing projects their own way – a Do It Yourself model. They may be using tools, templates, or processes that they developed, discovered, or borrowed and have been in their toolkits for years. There may be some common practices in the organization, but these are not fully documented or supported—just expected. I have often seen organizations provide a collection of templates as suggestions, not requirements.

Maturity Level 2: Documented Processes

At Level 2 maturity, the tools, templates, and processes for managing projects have been defined and documented. Level 2 is an interesting level of maturity, not so much in terms of what the documentation says, but how it was put in place. Obviously, the motivation for doing the documentation is that the organization expects its project teams to implement the documented processes. It is beyond the scope of this article to talk about how the documentation was created, but let me just say that if you expect someone to use your stuff, you had better give them an opportunity to participate in its development. Don’t risk the “not invented here syndrome.” This must be a team effort to have a chance at success.

Within the context of CMMI Maturity Level 2, if the tools, templates and processes have been vetted by the PSO and are a complete portfolio, then the HPMgt needs of the HPMgr would have been met.

Maturity Level 3: Documented Processes That Everyone Uses

The migration from Level 2 to Level 3 maturity is a big step. At Level 3, documented tools, templates and processes are vetted, supported and maintained. Compliance comes in many forms. In the complex project landscape compliance includes the adaptation of a tool, template or process to provide a best fit of the HPMgt process to the three constraints on the project. This is far more flexible than the original intent of Maturity Level 3. The PSO has to be open to suggestions for improvement from the HPMgr community and have a formal process in place for receiving and acting upon those suggestions. In the world of HPMgt, Maturity Level 3 may be the highest level that has business value. That is a topic for a future artricle.

Maturity Level 4: Integrated into Business Processes

This is best described by saying that project management has a seat at the business decision-making and planning table. At Level 4, effective project management is recognized as a critical success factor and a strategic asset to the organization. It is considered to be part of every business process or decision and a contributor to business value.

Much can be said about the organization that has reached Level 4 maturity. Project managers will have become very skilled in the business processes, and business analysts will have become skilled in project management. In this environment, project management is fully integrated into the business of the organization.

Maturity Level 5: Continuous Improvement

Maturity Level 5 is the pinnacle of integrating project management into the business. There is a formal and continuous program in place for process and practice improvement. It runs throughout the entire project life cycle. It formally begins during project execution, and continues through to the post-implementation audit and lessons-learned exercises at the end of the project. At Maturity Level 5 there is a way to capture these ″best practices″ and integrate them into the recommended tools, templates, and processes. At Maturity Level 5 every project team is constantly on the lookout for problems and offers suggestions for improvement.

THE ROLE OF THE PSO IN HPMgt

In the short run the best senior management and the Project Support Office (PSO) can do is provide a resource to support the hybrid project teams. To maintain some semblance of control that resource should be a portfolio of tools, templates and processes for managing the project over its life span. To further maintain comparability of performance between projects that resource should be vetted and the HPMgr encouraged to use only the vetted portfolio over the entire project life cycle.

The PSO will play a pivotal role. They will need a collaborative effort with the HPMgr community to build that vetted portfolio and then follow that up with a program that encourages project teams to use that vetted portfolio. No small task! I have previously written about that vetted portfolio [Wysocki, 2014]. Project managers must see that there is value in using the vetted portfolio because it is a supported portfolio. They are more likely to be users if they have participated in its creation and maintenance.

The Vetted Portfolio

The major strength of the HPMgt environment is that it places full control over the management of the project in the hands of the HPMgr. But that control would be a ticket to chaos if it weren’t contained within a portfolio of vetted tools, templates and processes. Having that portfolio in place and used presents several benefits and challenges to the organization:

  • the portfolio contains all of the tools, templates and processes that will be needed to satisfy the management requirements of any project that the organization might encounter.
  • the portfolio includes a continuous improvement process that monitors project performance and provides an open environment for project performance enhancements
  • the HPMgrs have a detailed working knowledge of the portfolio and how to adjust it to satisfy any project management requirements that might arise
  • the HPMgrs have the authority and responsibility to do what makes sense for effective project management

PUTTING IT ALL TOGETHER

CMMI was built for the Industrial Age project. We are in the Information Age. Maybe we need to rethink the CMMI in light of the movement towards a collaborative project management environment. The question to answer is “What is CMMI Level 3 Maturity in HPMgt? Rather than requiring compliance to a documented methodology it should define the methodology based on the characteristics of the project, the organizational environment and the dynamics of the market situation.

END NOTES

[Mullaly, 2017] Mullaly, Mark. “All is Not the Same in the World of Project Management (Projectmanagement.com), March 27, 2017.
[Wysocki,2014] Wysocki, Robert K., 2014. Effective Complex Project Management: An Adaptive Agile Framework for Delivering Business Value, J. Ross Publishing