Tag: Project management

Common Lean Manufacturing Software Project Constraints
Leveraging Project “Constraints” and Maximizing Results

As a project manager for demand-driven, lean manufacturing software, I have more than a nodding acquaintance with the theory of constraints (TOC). What I find quite remarkable is the ability to apply the theory of constraints to other mediums beyond the manufacturing of goods – even something like project work. When a client understands the theory’s principles, it can be powerful in driving a truly transformational project that outperforms their other software installations. It becomes a new way to frame how you and an organization collaborate to create something new – a better business with better and faster results.

If you want to learn more about how constraints management works in manufacturing, definitely check out my fellow blogger, Rick Denison. He’s the go-to guy for this practice on our site. What I’d like to talk about today is constraints management during projects—specifically—what are some of the more common project “constraints” and how do I deal with them?

Every project contains a standard set of parameters that become initially defined, but are continually balanced throughout the project lifecycle. These are competing project constraints, which include, but are not limited to:
- Scope
- Quality
- Schedule
- Budget
- Resources, and
- Risks[1]
These elements will pull against each other throughout the project, but it’s wise to identify them not as “bottlenecks” or issues, but as constraints that can be leveraged to drive outputs and faster progress. To give you some ideas about how to leverage these constraints, I will focus on three from the list: schedule, resources, and risks.

Schedule Time to Schedule

Sometimes people consider project planning a phase that can be glossed over so that the “real work” can begin sooner. Talking about the work does not accomplish the work, but it will make you consider ways to work smarter. Working smarter means different things to different teams, but can include creative scheduling solutions like:
- Several “sprint-like” mini projects instead of one big define-and-deploy project. This mini-project approach can mean functionality is delivered to business users faster and in more palatable scope amounts.
- Parallel paths of work to get more out of the project timeline.
- Understand the benefits of building in purposeful “buffer” time, which can at first seem like it’s unnecessary or that there’s no time allowable. I encourage teams to do this so that they protect the most constrained project resources and create a project system that is able to handle the inevitable, yet “standard” project disruptions, such as new business climate factors, changing team members, etc. Buffers are central within the TOC framework. Since the constraint resource becomes the pacemaker for the rate at which project deliverables are output, building in this time becomes critical to remaining on-time and not slipping in either schedule or scope.
It’s easy for a project team to complain about not having enough time in the schedule – even if they are just starting out. Instead, think about the full project timeline as a blank canvas and an opportunity to get creative on how to best leverage the time.

Your Most Valuable Resources are People

Your project team is about finding the perfect combination of two elements: quality and quantity. The “quality” of your team members cannot be overvalued. Capable team members that know their role, the business needs, and can deliver on the project objectives are the most valuable assets that any project could ask for.

But even top-performers only have so many hours in the day. Whether team members are allocated 25% or 100%, the important thing is to maximize the time, or capacity, that these resources have available. It’s not about labeling your most “valuable” resources, but inevitably, one team member will be a constraint. So, acknowledge the constraint and have everyone rally around the team member(s) to support their activities. In my experience, that means doing everything I can as a project manager to align tasks, schedules, and being extra-prepared for these specific (and valuable) resources.

The second leverage point to boost your project resources would be to add capacity by increasing the “quantity” of resources. When you have fully maximized the results from all of the current resources and are still not meeting the project scope, many teams consider relieving the constraint by increasing headcount. While this can be a helpful solution over time, be aware of the upfront time associated with bringing more people up to speed and that their output quality may not initially match others. Just like a manufacturing environment, additional resources (machines/assets) add to capacity, but require management and attention too.

Risky Business

Consider project risks to be like identifying project “flow disruptions” — ahead of time and concurrently adjusting course to mitigate those disruptions. Risks can range from small to significant, but discussing them openly and planning accordingly can sometimes be enough to avoid them all together. This means you increase the overall velocity of your project when you deal with less surprises downstream and you are able to deliver results to the business faster and with more clarity.

A team that does not spend time identifying risks throughout the project lifespan will likely regret it at some point. Discussing project risks can seem like more time taken away from “doing work” or a “gloomy” way to kick off a project, but it’s actually incredibly productive. The project paranoia that people raise can seem like an energy drain, but pay attention because often these concerns are based off of real experiences and legends of projects past from which the current team can learn.

The act of going through risk identification can surface two categories of topics. The first category is the potential risk scenarios for which a mitigation plan should be developed and executed. These would be the most common notion of project risks that people consider – the “what-ifs” and their consequences. The second category are issues that may seem like risks, but are really actual and necessary project tasks that were overlooked in the project plan. Be grateful that these were identified and plan them into your project activities like everything else, with a pat-on-the-back for your thoroughness in planning and the confidence in knowing you delivered a higher-quality output.

Next time, we’ll take a deeper dive into the project risks category and talk about ways to overcome them. Until then, feel free to send me your questions or experiences on anything implementation related.

[1] PMBOK Guide, 5^th edition

Sarah takes a customer-focused and results-driven approach to project management and demand-driven manufacturing systems implementation. With hundreds of projects under her belt, Sarah is fearless when it comes to challenging the status quo and delving into the details to ensure an optimal user experience. As such, her posts reflect tips and best practice advice for managing people and processes through projects – and getting the most out of your systems.
June 4, 2015
Life Hack 101: Doing Implementation Documentation Right
The Who, When, What and Where for a Solid Project Doc Strategy

Imagine if your most important photos—your child’s first birthday party, the day you brought home your new dog, that awesome vacation in Europe—were all lost forever. Your computer fell into the bathtub or the hard drive was wiped by an electrical storm, and you didn’t back up your drive. Don’t let this happen to your project documentation. Keep it accessible and functional for the life of your project as well as secure for future use, whether it’s for new end users, future implementations, or even project auditors. Consider the following and you will be on your way to doing documentation right:

You’ll want to figure out the Four W’s- Who, When, What, Where

Who? Who needs access and what level of access do they need? Do they have authority to sign off on documents, or are they just a viewer? Someone who can edit documents and share them? Define a few user groups according to their necessary level of editing rights. Use categories such as content Viewers, Team Members (creating and posting documentation) and Administrators. Also, be sure to get all individuals setup with a secure login so that they can access the information. Line up someone to be in charge of setting up and allowing new access requests for others. Be sure to designate someone that will be in charge of overall organization and version clean-up within the space. Sometimes multiple drafts of one document can get overwhelming, so you’ll want to be sure someone is tidying up along the way so that old versions aren’t confused with the latest drafts.

What? Now we’ll really need a good project tool with all of the built-in capabilities you need to ensure security, version control and ease of use. If the client company uses a Windows-based authentication system, this will work well with a number of collaboration tools, such as Microsoft® SharePoint or JIRA Confluence. These tools also make it possible for contractors, like partner company team members, to have project-specific login credentials.

Selecting a collaboration tool within the overall corporate IT strategy also means that the platform is supported and that retention policies are already in place for later access. Commonly, these collaboration tools are accessible via a secure Cloud for safe remote access and allow you much more functionality than just an electronic “file cabinet.”

As for the “what” to store, I recommend a certain baseline to get started, then some guidelines to execute and finalize the document repository:
- Blank, clean versions of all required deliverables
- Meeting minutes from any meeting where decisions are made and action items assigned
- Project management documentation (such as RACI, team contact list, charter, statement of work)
- One final version of all required deliverables in a folder marked “Final Deliverables”
- PDFs of final deliverables with written sign-offs from required approvers (each page initialed and signed on the approval page)
- Archive folders of older versions of deliverables or other documents
When? When should you set up the collaboration software or a documentation repository? It’s prudent to do this as far in advance of the project as possible so that pre-project kick-off communications or documentation can be posted to have an effective Day 1. Many companies have tools that they use to ensure a current version of the very first documentation. Dangerous gaps can form that leave crucial decisions out of the paper trail.

Don’t worry; you don’t have to have the entire organizational structure of the project down before you build your platform. This is just an address for everyone to visit and build from as you go along.

Where? You’ll need a location that is accessible to both the client and the partner team. If you host on your internal network, you might get into proprietary issues for client-side devices—and your partner team might not have the access they need. Work out any remote login logistics prior to the project start date.

The Email Error

I have seen personal emails between project team members disappear or cause serious problems in a project. Your “where” must definitely not rely solely on one-to-one emails that contain any project information that’s crucial to decisions or outcomes—basically, ask your team to add all necessary communications and information to the project collaboration space. Make it all public knowledge so the private email accounts of your project won’t leave gaps in your project depository.

Having a great place—a “where” that allows you to take action based on the most recent decisions—allows you to trust that your project documents represent all of the deliverables you need to track during the project and ensure that they’re not lost at the end of the line.

One version of the truth

You can tell that the overarching rules for project documentation are visibility and veracity. You need one version of the truth, for the right people, at the very beginning of a project and beyond.

Share your insights and any tricks you might have on project documentation done right. Also, send me any implementation questions or topics you would like to see discussed in an upcoming post. More tips of the trade coming up in future blogs – stay tuned!

Sarah takes a customer-focused and results-driven approach to project management and demand-driven manufacturing systems implementation. With hundreds of projects under her belt, Sarah is fearless when it comes to challenging the status quo and delving into the details to ensure an optimal user experience. As such, her posts reflect tips and best practice advice for managing people and processes through projects – and getting the most out of your systems.
April 14, 2015
Top 3 Communications Best Practices for Software Implementations

In a recent business article out of the UK, the author cites trends such as collaboration and connectivity as hallmarks of the “factory of the future.” I would take that one step further, and add “communication” to that list—especially during implementation.

Smart implementation leaders make sure they are listening to the insights of everyone who will be impacted by their new systems and following solid communication practices throughout the life of the project—and beyond. Here’s what you need to know about the three biggest opportunities great communication practices deliver to your project.

#1 Always be Buying (In)

A continuous goal of all communications is gaining buy-in from all project team members and stakeholders. I make it a personal goal to have all attendees, no matter what their role, walk away from meetings –or after reading emails –more in-tune with the overall project objective. Often we create increased sharing and discussion opportunities, so that communications can continue to be a two-way street.

There is a moment during every implementation where l watch the lines of communication open. I can see a new determination among everyone involved to follow through on our goals. Our communication practices had delivered that elusive element—buy-in—and as a result, each person becomes a project champion. Implementations like these sometimes herald the beginning of a culture change that helps the enterprise continuously improve by listening to and learning from each other.

#2 Living Documents Spur the Crucial Conversations

Setting up a communications plan and documenting results from the communications plan activities can help you ensure that you are in lockstep regarding action items, decisions, and project strategy. Documentation begins with a project repository – an accessible space where content and multiple versions of documents can be viewed, edited, and shared. In my last blog, we discussed how a good, solid RACI can help with workflow and accountability during the project. The RACI can stand as some of your first meeting notes and as a core project document to establish both project activities and communication expectations. A project repository “lives” in tools like SharePoint, Atlassian Confluence, or in other similar platforms.

Security and Sign Off

Documentation access and security should be a primary focus before and during a project. I recommend enacting specific security clearance for known project team members before the project begins to save time. You can always continue to manage access and permissions throughout the project lifecycle as both the team size and number of files may grow. The goal is to make sure your documentation is protected throughout the project, while having a transition plan for making the information viewable by a broader audience after deployment. The repository should be kept somewhere so that even many years after the project ends, the space is still accessible. You don’t want to rely on critical project information residing on an individual’s work station (what if it crashes!?!) so select a place that has staying power within the organization. It could be the only way you can conduct a corporate project audit, find original training materials or design documentation.

Push or Pull?

With all of the project content created, it’s important to decipher what makes good “push” versus “pull” information. Many project repository items will be best with a “pull” method, where users know where and how to go pull the information as needed. In other cases, such as project status updates, you will want to enact a “push” system where you distribute information to people so that it’s in front of them. The more you can schedule this regularly, the better. Often, this information supplies management with what they need to know for broader project statuses, such as reporting beyond their specific business or IT division. Information is pushed to them ready-to-use – don’t rely on people clicking links to be able to see and absorb it. You want it front and center!

#3 Understand (and explain) that Communication Delivers a Measureable ROI

People sometimes think that good communications is a “nice to have” add-on rather than a crucial element of the project plan. The folks at the Project Management Institute (PMI) are the masters at communicating well and at compiling solid research to show the ROI of your communications project. Most of their content is out there on the Internet free for the taking. Like this white paper, which has quotes like the one below:

“Among those organizations considered highly effective communicators, 80 percent of projects meet original goals, versus only 52 percent at their minimally effective counterparts, according to PMI’s Pulse of the Profession™ In-Depth Report: The Essential Role of Communications. Highly effective communicators are also more likely to deliver projects on time (71 percent versus 37 percent) and within budget (76 percent versus 48 percent).”

Those are some pretty solid numbers for building your communications business case, aren’t they?

Definitely let me know what you think about my top three—and if you have anything to add to help our readers make sure communication remains a crucial element in their project implementations. Until next time, then, keep communicating!

-Sarah Huhner

Sarah takes a customer-focused and results-driven approach to project management and demand-driven manufacturing systems implementation. With hundreds of projects under her belt, Sarah is fearless when it comes to challenging the status quo and delving into the details to ensure an optimal user experience. As such, her posts reflect tips and best practice advice for managing people and processes through projects – and getting the most out of your systems.

January 27, 2015
Rockin’ Relationships: Documents Drive the Details
In the second part of our three part series on successful implementation strategies, we discuss one of the most important project setup strategies – the RACI.

Part Two- The RACI

As I’ve mentioned before, implementation projects end up being mostly about the people involved. Project success hinges upon how effective the project team is in harnessing their own particular talents and in placing the right eyes over the right set of project deliverables to ensure quality down the line.

Last time, we talked about how to build a solid logistical framework for implementation. Next time, we’ll discuss effective communications protocol. Today, we’ll discuss the way to get the right people doing the right things using a RACI.

Don’t Race Through Your RACI

As you may know, a RACI is a responsibility assignment matrix that defines who is responsible for all aspects of the project. (RACI stands for Responsible, Accountable, Consult, and Inform). Based on an organizational matrix from the contractor and customer companies, it tells you which people do what to deliver all aspects of a project. So what do these four types of “project people” look like?
1. Responsible individuals are the people that will actually perform the work to complete a particular task or deliverable. These individuals coordinate all other team members who will have input or involvement on the task. This can include coordinating draft reviews, meetings, and sign-off to drive a task to completion. They are also responsible for communicating and reporting on the task progress. A good “R” assignee doesn’t necessarily have all of the information required to do the task up front. However, they should be on a logical team for the task, as well as in a project role that’s a good fit for knowing the task scope and how it’s going to get it completed. Note that a project manager is not a common “R” assignment within a RACI. The only exception is for project tasks that are strictly project management in nature. A great example of this is the RACI itself!
2. Accountable individuals have a role in signing off on a particular task and considering it complete to the highest quality. To be the “A” for a task means that person is signing off on the “R” person’s work. All content and language must be sound and clear, which is also what the “A” must enforce. If referring back to any designs that turn out to be incorrect or late deliverables, the Accountable person is the team member on the hook for explaining what happened. Having Accountable team members involved throughout a deliverable’s development is key to effective project work items. Final sign-off should not be the first time an “A” is reading content, but rather an affirmation of the already reviewed material. A proper Accountable assignment is one that has enough knowledge of the deliverable and project scope to know if something meets content quality expectations. If an individual is at too high of a management level, they may not have enough information to know if it’s been done to the proper standard.
3. Consulted – These individuals may be considered the Subject Matter Expert (SME) for a particular task or knowledge area. They are engaged by the Responsible team member to provide input and review deliverables for accuracy. A Consulted person’s expertise should absolutely be included before a task can be considered complete. It is important to identify the individuals specifically and communicate timelines and time estimates of when they will be needed. This makes sure they are available when required in order to avoid any project plan delays. For example, an architecture guru might need weeks to promise you attendance at a crucial meeting—make sure they’re on board from the very start.
4. Inform – These individuals will be provided status updates on a particular task or deliverable. They also may be just a user of the end product when the task is complete. An Informed individual does not typically provide feedback back to the Responsible team member – consider this role more of a “carbon copy” or “FYI” role that is copied on particular updates throughout the process.
The act of creating a RACI demystifies project responsibilities which will help a project be a well-oiled machine down the road. It allows people to manage their own time and workload within a project timeline since they know when and for what they are needed. I have found that the activity of doing a RACI is just as helpful as the resulting artifact. Make sure you have the crucial conversations about true responsibility and accountability to clear up potential confusion later in the project.

I’d love to hear about your experiences with planning RACIs. And I can’t wait to talk about good communications with you in my next post. But until then, keep your RACIs –and project relationships—rockin’.

– Sarah Huhner

Sarah takes a customer-focused and results-driven approach to project management and demand-driven manufacturing systems implementation. With hundreds of projects under her belt, Sarah is fearless when it comes to challenging the status quo and delving into the details to ensure an optimal user experience. As such, her posts reflect tips and best practice advice for managing people and processes through projects – and getting the most out of your systems.
December 1, 2014
Rockin’ Relationships: People ARE the Project

Logistics planning to enable project relationships – practical directives from an industry veteran.

Part One: Love Your Logistics

At the end of the day, implementation projects end up being about people—their skills, styles, and investment in the project and the project’s success.

As you may well imagine, there are quite a few ways to set up effective relationships. For me, these fall into three categories: Project documentation; communication: and logistics. And whether I am working on an overseas project or around the Midwest, logistical considerations sometimes loom the largest in starting off a project on the right foot.

In the other two sections of this “Rockin’ Relationships” blog series, we’ll discuss documentation strategies and communications best practices. We’ll obviously have some overlap in these areas. But in the meantime, we’ll concentrate on logistics, using the five ”W’s” and the one “H” of journalistic renown.

Who? It’s easier to retain control of a project when specific people become associated with each project deliverable. I also recommend pairing these individuals on-site with a corresponding member(s) of the consulting team. It enables them to cultivate a level of comfort with one another that can lead to open lines of communication – discussions that send so-so projects into the stratosphere.

What? The success of any project depends on how task-oriented its team members are. We’ll talk more during the rest of the series about documenting these tasks, but, logistically speaking, this question has to do with the nuts-and-bolts of the project: What do our teams need to succeed? These items range from specialized laptops to on-site building access cards.

When? Make sure your repository includes timelines for when certain members of the consulting group will be on site. Also get the few selected regularly scheduled meetings on the calendar right away and require that people rearrange schedules to accommodate them. Holding all team members even to an initial, high level timeline will begin to drive the project toward on-time delivery. We’re talking about production software here, so of course, on-time remains a pressing concern for our industry. Don’t let your project be any different.

Where? Make sure the consulting team has a workspace and the proper introductions to the key people responsible for the project. This may seem like a no-brainer, but I have seen consulting teams literally headquartered in a closet, waiting for building or server access for weeks. As you may imagine, this doesn’t help with the project budget.

Why? Logistically speaking, taking the time to explain to members not only what you will be doing but why you have done it this way will help you obtain buy-in—the project manager’s most precious commodity of all. The more people understand the project priorities, the more supportive teams will be later in the process.

How? Crafting a solid Statement of Work document will help you ensure that the people involved with each phase of the project are clear on scope. Approach it like a lawyer would, even perhaps before a lawyer reviews the document. If the Statement of Work has already been established when you join a project, read it through enough times to be able to explain it to someone else at both a high and detailed level. If you have questions, ask your leadership team in case it leads to a potential scope loophole later on. Show the team you have a clean grasp of scope and they’ll feel secure that you know how to get everything done, on time, and with the right resources.

These are just a few of my takeaways from being on my own project management journey. I also urge you to send me some of your own project logistical tips; or send comments or questions about what you’ve read here. I can easily tailor future blogs to address them and would much prefer these pages to reflect a conversation rather than a lecture!

If you are responsible for implementations from a client standpoint or even in another industry or for another vendor, I’d like to invite you to share your experiences, as well. We’ll continue our discussion about managing relationships effectively in the next two blogs. Until then, keep those implementations rockin’!

– Sarah Huhner

Sarah takes a customer-focused and results-driven approach to project management and demand-driven manufacturing systems implementation. With hundreds of projects under her belt, Sarah is fearless when it comes to challenging the status quo and delving into the details to ensure an optimal user experience. As such, her posts reflect tips and best practice advice for managing people and processes through projects – and getting the most out of your systems.

November 4, 2014

“test”

White Paper - The Next Generation of Planning and Scheduling Solutions

White Paper | Gaining Clarity

Test_form

White Paper | Gaining Confidence

White Paper | Gaining Confidence

Please complete and submit the following information to download the white paper. Thank you for your interest in Synchrono!