Tag Archives: project management

4 Considerations When Choosing Project Management Tools

by

Project Managers tend to be very opinionated on the “right” PM tools to use. This discussion, and interview question has always frustrated me. I strongly believe that it doesn’t matter what tool you as the Project Manager prefers, you should be able to adapt to whatever tools work best for the organization and your customer. If you Google “recommended project management tools” or “the best project management tools” you can between 34 million and 125 million results. In my experience, there are four key considerations I use for the basis of deciding which tools will work best.

Which-direction-Fotolia_50558549_XS-300x221KISS

Keep it Simple! The least common denominator is usually the best option. Tons of fancy features aren’t generally very helpful. Often times you pay for the luxury of having those available. Apply the 80/20 rule to your evaluation process – 80% of of your needs will be fulfilled by 20% of the features & functionality in most project management tools.

Audience

Who is your audience? The tools you leverage with your project team or for your own planning will probably be different than those you use with broader stakeholders. I have found that simple tools are often best. While I can develop a complex gantt chart, and will sometimes do so for my own planning, I find basic word-processing & spreadsheet applications are easier for less technical (or PM focused) audiences.

Proximity

Is your audience within or external to your organization or team? Often times you need to deliver project status and meeting notes to an audience with internal and external participants. These are more static update tools, rather than interactive. These tend to capture status, action items, changes, decisions, etc. This is the right tool for conveying priority or tasks to another team within your organization where you may share resources. Additionally, you will want to figure out how to make project artifacts easily accessible. This may be through an intranet for internal access only, or a collaborative/extranet solution.

If your audience is located in your same office, I would highly recommend using tools like white boarding and sticky notes to brainstorm and organize. Recent studies (here’s Inc’s write-up) have shown that leveraging less technical tools improves creativity and brain power.

Feasibility

This consideration encompasses cost and availability. Sometimes your decision is just made for you. If you are running your project budget or organization very lean, you’ll want to leverage open source or free software. Alternatively, if your organization has negotiated a software licensing deal that gives you access to specific tools, it may make the most sense just to use what’s available.

At the end of the day, don’t overthink your tool selection. Decide what your critical goals are, and find the tools that meet them. There are significant advances in project management tools that provide plenty of options. Not all of them are right for all projects, teams or organizations. Sometimes it best to get everyone in the room, using the most basic tools of all.

The Myth of the Project Plan

by

 

The Project Management Institute Project Management Book of Knowledge defines a “project plan as a formal, approved document used to guide project execution and project control.” It further specifies that “it should be used to document approved scope, cost, and schedule baselines.” In my experience, a project plan is treated heavy on the “formal” and “approved” and light on the “baseline.” I think the process of approval gives the perception of longevity on the life of the plan. This minimizes the impact of the project plan as a baseline. Unfortunately this misunderstanding causes many complaints about project delays and delivery.

I was struck by this Computer Weekly quote when I conducted a google search for “project plan”: “[It] is one of the most misunderstood terms in project management. It is a set of living documents that can be expected to change over the life of the project.” This is polar opposite to how I have seen the project plan treated. The project plan is usually created at the beginning of the project, based on a statement of work, with fairly limited information. Even in cases where all stakeholders understand that the project scope is fluid, the project plan is expected at the beginning of the project and is used for making time-specific business decisions (training, user acceptance testing, etc).

Historically this has resulted in project managers padding their project plans with additional time so that the project is guaranteed to come in on time. Alternatively, the project plan isn’t padded, but issues of either scope creep, or scope reduction occur. In all cases, decisions are being made to meet a deadline, often selected artificially, which only aligns to the information available at the beginning of the project. There is no consideration to the fluidity of project implementation and information availability.

It would alleviate quite a few problems in project delivery & success if we chose to leverage the project plan as a living, breathing document. As time progresses, and additional details are obtained, the project plan should be updated. As a project team, we would be in a much better position to make decisions, and set more realistic deadlines as we get into the details and work through the development. Furthermore, sharing regular status and having constructive conversations about the state of a project and the next steps result in a more successful deployment. 

 

 

3 Pitfalls with Allowing Technical Teams to Engage Directly with Clients

by

We all inherently know that our best options are to always to go directly to a source, whatever or whomever that is. In a recent post, I advocated for allowing your project team to engage directly with customers. While I strongly believe this allows you to deliver a better experience, I do think there are a few pitfalls to avoid.

bomb_clip_art_10552 1) Be careful about the “shoot from the hip” responses – Often times in design or business discussions an inquiry will ask “how long?”, “how much?” and it is common for people to “shoot from the hip” and give an answer. There must be a structured way to balance these casual conversations, with the reality of the project status, plan, resources, investment. Otherwise, you will get stuck in the never-ending project and perpetual scope creep.

2) Balance gut estimates with discovery – Everyone is in a rush to understand how long it will take to build this product, feature or system. You need to be able to leverage your knowledge of having done similar applications, with the project discovery you need to do to understand this particular project. Too often I’ve been caught in situations where I had to explain that while a team member said they had done something similar in 10 hours, this particular implementation was going to 40. At initial thought, this seems excessive, as compared to the similar project. However, once you start talking about all the additional project management, testing and discovery required for this one versus that other one, it becomes more palatable. Make sure you vet gut estimates with actual requirements and customer needs.

3) Avoid detours – A huge risk to allowing project teams to engage with customers directly is subtle permission this introduces to go directly to the project team. I’ve seen customers who will stop engaging with ticketing systems in lieu of going directly to project teams. This introduces quite a few disruptions to the process. First it makes tracking and accountability difficult as inquiries aren’t going into a central system. Second, it can overwhelm project team members as they try to balance assigned work with the customer engagement. The project team will sometimes feel that they “have to respond.” The project manager or customer success manager needs to step in and manage the process. The team needs to make sure that they are being responsive, but doing it in a way that addresses the customer priorities, and keeps the customer involved in making those decisions.

As I’ve mentioned before, I’m a huge advocate for engaging project teams with customers. This is not a free for all. There should be a structure and methodology, with appropriate accountability and check points to adjust for the changing environments.

4 Ways Project Managers Deliver Quantifiable Value

by

It is sometimes hard to understand the quantifiable value that strong, technical project managers bring to organizations. I would go one step further and say that some people question the value (of any kind) that project managers bring to the table. Like many in operational roles, project managers are blamed for project challenges, but are often overlooked after project successes.

I searched Google for articles on how project managers deliver quantifiable value. Mostly I found articles that were more conceptual in nature about why you need a project manager or project management office (PMO) or how to get the most value out of your PMs. I didn’t find tangible ways project managers actually improve the bottom line of the organization. In an age where every function needs to be delivering quantifiable value, I was a bit surprised. I know that strong, technical project managers are invaluable to organizations, and worth every penny of their cost.

Project managers deliver Quantifiable Business Value by:

  • Reducing busy work & obstacles for the project team – It has been proven that focused, dedicated time improves the quality and reduces delivery time of technical solutions. A strong PM will handle the busy work, allowing the team to do just that. Cost savings:  Reduced hours worked for project delivery & reduced hours of non-billable rework.
  • Managing the analysis & artifacts – This is an often overlooked function of a PM. A good PM will understand the business requirements and can help facilitate troubleshooting & testing. Additionally, the PM will also be able to write & manage the artifacts (project plans, requirements, implementation documentation), which become most critical during testing & supporting the development post-implementation. Cost savings: Reduced costs for testing, support & maintenance and facilitation of support functions away from high cost developers to less expensive support resources.
  • Reducing risk – A project manager will feel comfortable managing the scope, and making decisions. The PM is willing to have those tough conversations for prioritization. Cost savings: Reduction or elimination of unanticipated costs associated with scope creep. Additional cost savings come from keeping project on schedule.
  • Improving project delivery &  allows for new work – Lastly, and arguably most important, a good PM will deliver! Often organizations get bogged down by lack of prioritization resulting in all resources making their own decisions. This chaos slows the progress of project delivery. For all the reasons outlined above, a PM will delivery projects, which will open the window for new work from customers. Incremental revenue: When PMs deliver, customers deliver too! In this case, it’s in the form of new work.

Don’t under estimate the power of a strong, technical project manager for the success of your business. While you may wonder if you can afford the cost, I would argue that a PM can pay for themselves in what he/she delivers in return.

 

3 Considerations When Managing Globally Diverse Project Teams

by

Global project teams happen more often than not these days making it no longer feasible to get everyone in a room to facilitate a project. As a Project Manager & leader for both global team members and global customer teams, I’ve experienced the added complexity of this on my projects.

A LiquidPlanner blog post by Tim Clark from October 2013 “7 Tips for Managing a Global Project Teams” highlights time zones, cultural, religious, and sociological differences. Mr. Clark also recommends staying on top of advances in software solutions to simplify the process.

Global Teams

My Experience with Global Teams

Inc. published “5 Tips to Manage a Team Across Multiple Time Zones” by Will Yakowicz in July 2014, which also had very applicable information. Mr. Yakowicz reminded us that we can’t work 24 hours/7 days a week, emphasizing a consistent schedule. He also encouraged us to leverage the latest technology, invest in airfare to facilitate team cohesion while also recognizing that we must be extra aware of those people who aren’t sitting in the same room as us.

In my experience, there are a few additional key considerations for successfully managing global teams.

  • Be Flexible – As the project manager, it was my responsible to facilitate the project. Some things do just get lost in translation over email, and it’s necessary to have a phone or video session. Unfortunately, it’s not all about me, therefore it can’t be all about my time zone. I often had calls in the early morning or late night to coordinate with Europe (EMEA) or Asia (APAC) as required.
  • Be Available – When you have remote teams, it is imperative for each team member to be more communicative than would be required if everyone was in the same place. I can’t hover at someone’s cubicle when they are based in Ireland, but I can make myself as available as possible, as well as encourage each of my team members to do the same, on any mediums used by the respective regions.
  •  Diligently Break Down Barriers – Communication is hard. It’s even harder when you’ve never met a person, other than via email or phone. More often than not, when you are driven to a phone call it’s to resolve an issue. I encourage you to take the time to introduce yourself and chat. By learning the personality traits, and what drives your team, you will be better able to motivate them.

Managing global teams is difficult. The pace of project delivery, technological advances and life adds to the complexity. However, it is the new normal. We’ll need to step up our game to learn to do it well.

Professional Services Organizations: Do your Project Managers Create Work or Remove Obstacles?

by

I’ve had several conversations lately with software developers or business management regarding project managers, and whether they create work or remove obstacles. As a project manager myself, I’ve felt that removing obstacles and allowing resources to focus on the tasks at hand is one of my top priorities.

In researching this issue, I found a September 2005 article by Scott Berkun “The Art of Project Management: How to Make Things Happen” that highlights that the ability for people to move project forward (AKA remove obstacles) is a skill that some people have, but others do not. Berkun proposes that this skill comes down to knowing how to be a catalyst in many situations, while also having the courage to do it. Additionally, projects move forward more when: prioritization occurs; “no” is accepted and appreciated; open & honest communication occurs; the critical path is known and the PM is relentless & savvy.

PM Technical Skill to Execution Matrix

PM Technical Skill to Execution Matrix

A more recent article published March 16, 2015 in MITSloan Management Review by Alexander Laufer, Edward Hoffman, Jeffrey Russell & W. Scott Cameron “What Successful Project Managers Do” emphasizes the organizational responsibility required to allow project managers to be flexible. This research article states that project managers need to: develop collaboration; integrate planning & review with learning; prevent major disruptions and maintain forward momentum. This ultimately results in a more fluid, adaptive project.

As projects have become significantly more technical in nature, the divide between project managers who create work or remove obstacles has become more pronounced. Technical implementation projects push this even further. As project leaders, we need to recognize the impact of technical skill and the too many active projects on ability to manage a project to its completion. There are 4 combinations on the technical skill to execution matrix:

  • Technical but Overworked – These project managers have the skill, but are not capable of removing obstacles because there are too many other projects on her plate.
  • Technical & Actionable – These are the technical project managers that are able to remove obstacles for their team. Often these resources get overlooked by the project team as they are seen as just doing their job.
  • Non-Technical & Actionable – These resources tend to be PMI certified so know the mechanics of managing a project, are able to remove obstacles without needing to fully understand the technical pieces.
  • Non-Technical & Overworked – These project managers also tend to be PMI certified so know the mechanics, but are overworked so they can’t focus on removing obstacles. Ultimately these pieces get pushed to project resources.

As a technical project manager, I have some bias about which quadrant the rockstars reside. However, there are some strong non-technical project managers who are able to successfully complete projects. This requires management support and a level of organizational prioritization that is really difficult.

Project Managers: 3 Tips for Managing Project Schedule When Client Expectations Don’t Match Implementation Timelines

by

There are often misalignments in the available time for a project implementation and the full range of work that needs to occur. As a technical project manager, I have managed this scenario many times as a result of optimistic sales schedules, distorted expectations of the custom software implementation (versus installation of out of the box software) or a variety of other reasons.

Kenneth Darter wrote in a in March 3, 2014 blog post on ProjectManagement.com that there are 3 Methods to Managing Customer Expectations: Optimistic, Realist and Pessimistic. Different organizational groups lean towards different methods. An optimistic approach can result in customer & team frustration when hiccups or schedule slippage occurs, while pessimistic approaches sometimes breed mistrust as the estimates are so padded that nobody believes them. Realism in project estimation requires significant a solid understanding of the team players, the work that needs to happen & client expectations.

PM_constraintshttps://www.projectsmart.co.uk/understanding-the-project-management-triple-constraint.php

As Duncan Haughey pointed out in his December 19, 2011 post on Project Smart, it is often said that there is a 3-way constraint In all projects between cost, time and scope, with quality assumed. This has recently evolved to a 4-way diamond of cost, time, scope, quality, with customer expectations as the foundation. Without understanding the customer expectations, it will be incredibly difficult to you make the right decisions regarding cost, time, scope or quality.

Regardless of your primary method for setting schedules, you will always need to take into consideration cost, time, scope, quality, and most importantly customer expectations.

  1. Communicate the Facts – In reviewing the list of work before a weekend migration project, it became apparent that there were more machine hours of work to migrate some historical data than existed in the weekend of the deployment. Armed with the facts, I was able to talk the client into reducing the scope of the historical data migration for the deployment weekend and plan for remaining work after the fact.
  2. Discover the Business Motivation – During a data integration project with aggressive timelines, a client requested 2 weeks for internal validation. After initial pushback, it became apparent that the issue wasn’t our work, the client had data quality concerns from the source and needed to determine the impact to the business. We were able to tweak our approach to the project to help mitigate some of the concerns.
  3. Be Vigilant – As a project manager it is imperative to keep your pulse on the project. When snags occur (and they will), you need to communicate loudly and often to ensure the project team and the client understand what happened, why it happened and how it’s being resolved.

At the heart of every project are the client expectations. While there is an inherent quality you should push your project team towards, cost, scope & time will all radiant around the expectations and adjust as required.

favoritepicDagny is currently Managing Director at Digital Ambit, a consulting company focused on helping you with your data and software integration needs. Dagny has almost 20 years of experience in project delivery & customer success of software implementation projects.

 

Lessons Learned from Planning a Job Fair with a Volunteer Army

by

I’ve spent the last five months planning a job fair using primarily a committee of volunteers.  While event planning is done every day by event planners, and marketing folks, this was ultimately a 500 person event spanning 3 hours, plus another 2 for setup.  I have had small roles in larger conference planning for prior companies, but have never had this as primary responsibility.  I learned a lot in the process.

1.  Be organized – The number one lesson to planning a successful event is organization.  This seems obvious, but can be challenging when dealing with volunteers.  Often times, documentation from prior years resides in people’s heads rather than on paper.  Take the time to lay out what you need to accomplish, with goals, rough timelines and fill in the rest as you go along.

2.  Use all of your resources – I had a primary committee who worked on job fair planning, but I was not shy in reaching out to other committees that had a shared interest, or could help us.  This event is a core benefit for sponsors so it made sense to really engage and integrate a sponsorship committee liaison.  We had several conversations with communications about what they will do and how we needed to target our audiences.  Additionally, there were reasons we had to rely on our main office for support.  It was a collaborative effort, but make sure you don’t lose sight of the end goal.  You can’t single-handedly accomplish a successful event on this scale without taking people up on their offers, and asking for the assistance you.

3.  Try new things – I felt my role as leader of the event planning team was to generate new ideas and expand our reach to make this the most successful we could.  This meant being willing to identify new exhibitor prospects from county lists of honored companies, reaching out to small growing organizations who might not previously engaged with the organization, and incorporating more social media marketing.   Each of these ideas were successful in varying degrees, but we wouldn’t have known that without testing the ideas.

4.  Have a backup plan – Whenever new ideas are introduced it is imperative to start thinking in terms of backup plans.  For us this meant being creative about where support service organizations would be positioned within the job fair; inviting wait listed companies to attend the event to network, but encouraging them to check-in to see if any tables opened up (2 did and were immediately filled as a result of this contingency).

5.  Over communicate – It is imperative to make sure you are over-communicating.  There isn’t the luxury of patiently waiting for something to happen.  Lay the information out for everyone involved to see and know and meticulous track your progress along the way.  This allows you to adjust as ideas positively or negatively impact your target outcome.

6.  Shameless promotion – As the leader of the planning committee it is important for you to be seen promoting your event.  Even if your network is small, your committee and those involved need to see you putting the event out there.  This will encourage them to follow in your footsteps. This should be done at all stages and for all audiences of the event.

7.  You can’t please everyone – All you can do is make sure everyone is well informed about what’s happening and you are doing your best to make sure both exhibitors and attendees are as prepared as they can be.  You can not control exhibitors participation – from providing details for job seekers so they can research in advance; presenting their company with engaging displays, table decorations or give aways; or actively engaging job seekers.  You can merely provide the tools for their success, but at the end of the day there is only so much you can control.

I had a really good experience.  I had a great team who helped guide me through the process, and staid on top of their own tasks.  We had 190 recruiters and 300 job seekers, with few hiccups and very positive feedback.

Scrum and the Art of the Obstacle Course

by

What do you need to get through a complicated, every changing software development project and a Tough Mudder obstacle course?  A great team is a good starting point.

This concept isn’t new.  Ken Schwaber and Mike Beedle talk about it in “Agile Software Development with Scrum.”  They liken building software to running an obstacle course.  “Agility, flexibility and adaptability are required to succeed (p 99).”  They argue that following a set plan won’t get you to the finish line.  It is the art of balancing everyone’s skillsets, collaborating at each step, and openly communicating that allows for software development success.  Schwaber and Beedle further push the point by emphasizing that the team needs to self-organize and lead the efforts.  A manager, project owner, product owner, or other stakeholders can only assist the natural order of the team.

This resonated pretty well against everything that I heard about the Tough Mudder, and similar obstacle course races.  The Tough Mudder started with a 30-something fit men demographic who could probably “brute-force” their way through many of the obstacles.  That demographic has evolved to include 80-somethings and more fun focused teams,  In all cases, it has become less about “brute-force” and more about collaborating on the best solution.  Competitors have challenged Tough Mudder obstacle creators by using obstacles in unanticipated ways.  Like the agile team, a coach is going to be able to provide minimal support during the actual obstacle course.  It is his/her job to prepare the team for the challenge and eliminate hurdles prior to show-time.

Having managed multiple software development projects, this approach seems pretty intuitive.  Each team member knows their strengths, weaknesses and skillsets.  They will also be first to see the challenges.  Therefore, it makes sense for the team to to manage themselves, with a coach to nudge them in the right direction.  This approach requires an incredible amount of trust between team members.  Once this is established there should be a cohesive and collaborative group to overcome the typical challenges in software development.