Tag: Project Accountability

  • Life Hack 101: Doing Implementation Documentation Right

    Life Hack 101: Doing Implementation Documentation Right

    documentation

     

     

     

     

     

     

     

     

    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 HuhnerSarah 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.

  • Top 3 Communications Best Practices for Software Implementations

    Top 3 Communications Best Practices for Software Implementations

    Synchrono blog

    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 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.

  • Rockin’ Relationships: Documents Drive the Details

    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

    RACIAs 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

    6.0-Sarah                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                            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.

“test”