When faced with a new type of project, I often find myself questioning if my usual approach will work. My proactive nature helps me to think ahead and tweak processes and documentation to fit the new project’s efforts. Unfortunately, with my last project I ventured into new territory and found my doubts were correct. I ended up in a situation where I was constantly scrambling to manage situations instead of being able to be a typical forward-thinker. To briefly outline the situation, my project had the following issues:

• Lack of business requirements because teams did not know how to gather them, much less document them.
• No product owner or partner that was responsible for the product/project.
• Refusal to be accountable for defining requirements.
• Lack of knowledge about the technical and advertising processes (I had a new business team).
• Fear of commitments - time, dates, etc.
• Little technology knowledge regarding development cycles.
• Little product knowledge (about the product they owned).
• No understanding of the acceptance testing process and how to execute it.

Ouch right? The funny thing was that despite all of my standard planning, I didn’t know any of this until after we had kicked off the project. Regardless of the challenges we had, the team was fabulous to work with and we muddled through. At the end of the project, I found that I’d learned a lot and had positive ideas to take forward in my career.

My First Step: Review the Lessons Learned

As you saw in my list above, I carefully identified all the problems in the project. What I found was that within my PMO were several newbies working on projects and struggling with the same things. We were all leveraging our standard practices and encountering the same issues. What a great thing, actually. While it made us all a bit uneasy, we were smart enough to leverage each other and document all the pain points so we could start work with our management team and define a new process for this project type. Once I reviewed my lessons learned list from the PM team, I found that most of the issues could have been addressed by following the standard process for setting up a project:

1. Get Your Team Set Up: If you don’t have the right resources on your team, your project will fail. If you are proactive and/or experienced enough to see the possible issues before you get to them, you may not fail but the ride will be bumpy. Go back to your basics -- get an RACI out, document and then sign off with management support. While I understand that is a basic thing to do when setting up a project, it’s not always done the proper way. The seasoned PM may get a tad lazy and make some assumptions. What I found was that I missed some things early on that might have helped me flag to management the potential issues coming. With that said, I actually did dig out the RACI and document all the roles. What failed me was the commitment level of those people on the list. I actually had a product owner tell me within weeks that he was not going to learn the product -- he wasn’t interested in doing that. Great! While I flagged it, I should have demanded commitment from management or gotten a completely different resource from my business partner. Management didn’t seem to consider it a risk and asked us to just move forward. What it comes down to: make sure you know who is on your team, get all the roles filled and gain commitment from the resources assigned and their management.
2. The Right Documentation is a Must: When you’re starting out in a new place or with a new project type, be sure to identify all the project deliverables and documentation. If you’re unsure of what will work, seek out advice. With all of my Agile experience and waterfall experience, I saw this project wouldn’t fit. I had to be very crafty about how I set the project up and work with several other PMs to understand the issues. The challenge here was that nobody had any advice for me. I was on my own. I found that there were a few key people on the team who were willing to jump in and do whatever it took to get the project done. While that was good, my documentation as a PM was crucial. My solution: In addition to the required documentation, I took detailed notes. My notes were not just on decisions but on general conversations. I learned that memories are short, especially when what happened wasn’t in the other person’s favor. But since I was learning the issues quickly, I had to cover my bases.
3. Set Up the Rest of Your Project: I won’t review the basics here, but be sure to take care of all your needs before scheduling a kickoff. Get your project plan, schedule, resources and other items taken care of before you get going.

Fortunately, I one thing that helped me immediately (and will help in the future): I built good relationships. I knew I was in a tough spot and went back to my business basics. As a PM, it’s important for you to ensure that your team trusts you. If they don’t, or if you are at odds with its members, they’ll be far less flexible. I made sure to communicate with all the key people well beyond the norm. Because I had taken the time to do that, communications became much easier. It also made the team want to work harder because we had more skin in the game. We didn’t want to let anyone down. In this instance, I was lucky: My business partners and tech team were very nice folks. It was more in their nature to build relationships and do whatever it took to get the job done. But I always bear in mind that next time I might not be so lucky. How do you build those relationships?

• Meet frequently with your manager to provide updates, status and discuss any open items. If you’re on a tough project and the business team calls your manager, you want to ensure he or she is equipped with the latest information so he or she can speak to the situation at hand. As a PM, it’s your job to ensure your manager is successful -- not just your project. When managers are knowledgeable they can help you in ways you may not expect.
• Meet frequently with the project sponsors: Mine was not in the same city as I was, so I did whatever I could to build our relationship. I never relied on email. I always called as my first line of communication, even just to provide updates. Just calling to say hi goes a long way to building trust.
• Build a partnership with your team lead: My counterpart on the business team was the business analyst. I made sure that I developed an appropriate relationship with him early on because he was the one to whom I had to deliver my updates. I found that once I built that trust, it was easier to provide any update. He trusted me. It also made it easy to read the signs of when things weren’t settling right and gave me clues to follow up later to make sure he didn’t have any side questions. I did this through frequent status reports, detailed emails, phone calls and a true desire to work together.

Defining a New Process

Another thing I had to do was create a new process. Not for this project, but for my next one. My new process includes helping the business partner understand several things: How to create valid business requirements, content, variable documentation, preparing for user acceptance testing and leadership. Because business teams aren’t typically required to provide business requirements, I found myself having to learn about their business more than is typical. Some of my new processes and documentation were specific to the advertising or education industries, but the principles can apply to all industries. It’s about helping your partners be prepared. Also, in cases were you need to be more involved with the initial project efforts, remember to ensure that there is an appropriate budget that accounts for your extra time. In order to support the project’s documents and needs, we defined them in an Excel file and created a tab for each. By keeping all details in one document, we could better track the project. It also provided traceability of development and testing back to the original business needs and requirements. This is what the process now looks like:

• Define Business Need: This is typically done solely by the business partner. We rarely get much more than a single piece of paper with some notes jotted down or typed up. We have to take this item and pull back to create the strategic documentation with the partner.

We do this by requiring the simple statement of need and holding brainstorming sessions with our partners to generate their documentation. It’s not what I’m used to doing, but each environment defines how you have to work. If you’re finding that it’s difficult to obtain usable strategy documents and business cases, start defining them yourself. Sometimes it’s easier for people to react to and approve items than it is to create them from scratch.

• Define Project Scope and Business Requirements: This should also be done by the business partner, but again they’re often not able to define this well. So we create a list of statements and hold a brainstorming and decision-making session to finalize this effort. We see this process more as a training opportunity with our partners. As they become more educated and aware of the real needs, they will become better at providing the correct information to project teams.

• Define Visual Design (UI or Printed Design) and Content Design Documents: This is a different approach to IT projects. Often there is content that needs to be defined for pages, screens, errors, etc. If you’re working on printed materials, coursework or anything that requires copy, then you need to define these two documents. This can be done through visual mockups with PowerPoint, Word or any other program that will allow you to draw basic shapes.

These two documents support overall design and functionality. This is not something that I’ve typically seen in the project documentation. I mostly see “copy” and “design” specs set up in a functional specification document. Some may argue that it should be included in the Functional Specs. While this can work, I have found that my current business owners do not 100 percent understand those documents and need full visuals to move forward. These documents are kept with the original scope and business requirements Excel file, just in a separate tab.

Also, we found that keeping them separated and referencing IDs helped the QA team support their test plan and test-case development. That goes a long way as we progress through UAT.

• Functional Requirements and Technical Specs: This is standard documentation. The difference here is that once the team gets to the point of creating these materials, it should be better-equipped to understand the needs of the business partner. All of the higher-level details for these documents should be vetted in conversations as they’re created. The business owner shouldn’t be surprised with how an item will function.

• UAT Process: Once the team moves into development, the users can start focusing on the UAT timeframe. I am on a mission to educate business partners on how to conduct a successful UAT program. I find that most owners who have not been involved in the past are reluctant to step up in any manner. They want the technical team to do all of the work. That would be fine except this is user acceptance testing – it’s the users who need to do this work. I’ve created some training materials and processes to help define this and move UAT along.

One item I have changed up since my UAT discussion is when I start the process. Now, I immediately start the discussions and kick off UAT as soon as we move into development. That way we’re not rushed and can leverage the knowledge we gained from compiling the requirement to create a test plan and test cases. My goal is to slowly educate my business teams and be able to, within a few projects, pull out of doing any true management of UAT and just facilitate the meetings.