Got a big project? Make a plan and work the plan.


It has been a while since I wrote last time. 2017 is flying off fast.
My move to Dominion Dealer Solutions has been a wonderful journey. I have been lucky to be leading a team of veterans and working with few leaders in the automotive industry. They keep teaching me a thing or two every day. With all things coming to my On-boarding and Deployment Services team, some days I am drinking from a fire hose.

My most recent project involves Dominion's swapping out an existing partner data feed from one technology stack to another. Data feed is receiving 100's of files every day from the external partner and pushing their contents to multiple internal targets in different formats. Current feed and process works. With upcoming retirement of that feed the partner, we needed to upgrade.

Sounds easy, right? Well, let's just say some things went right, some went wrong and some went arguably in-between. In the end, we all are learning a few things as we are nearing the project's go-live mode.

I acted as PM for my team that's part of the large project team and a stakeholder to the overall project.
Here's a few of my observations and lessons learnt in the form of advice. I have put them into 3 main categories: product, process and people. I consider all 3 to be vital for any successful technology project.

1. Product: Don't miss this one.

  • Product equates to deliverable of the project here. Know the existing product(s) and services in place. Chalk out the future state of the products and services. In a data project, get technical experts to help you with AS-IS and future state artifacts. Do not make assumptions. If you are a newbie (in the company) like me, keep bugging people until you have validated all information by multiple parties.
  • What are the business and technical deliverable in the project. Development and test plan discussions may not have to wait on contracts and certifications. Can you isolate them and get parallel teams working on them? Do discuss and decide.
  • Is training and support part of your project? Plan accordingly. If they are not, do talk about it and move on.
  • Spend good enough time on product/services deliverable. Don't rush this. Get written agreements on "Definition of done" and publish to all stakeholders.

2. Process: Put them in place early. Flex and adapt accordingly.


  • Build your documentation site/location for all documents and communications on Day 0.
  • Discuss and decide on tools, tips and tricks you will be using to keep things moving. For large teams working in multiple physical locations, centralized project plan in addition to agreed-upon issue tracker is MUST for a project. Don't let individual or teams to veer off and begin storing issues/tasks in tools that are not visible to and agreed by all teams.
  • Discuss and decide SLA for issues. You are ready to jump through hoops for any task in your project. What about others? Get agreements on time-to-resolve by issue type/size.
  • Plan out your Software Development Life Cycle phases quickly: 
    • Requirement gathering and analysis.
    • Design.
    • Implementation or coding.
    • Testing.
    • Deployment.
    • Maintenance.
Can you treat each of these phases into individual agile sprints? Agile and SDLC don't collide. Agile is NOT an excuse for missing steps and taking poorly thought out shortcuts.
  • Plan daily stand-up meeting and make it mandatory for project team involved in each phase. This should be short and sweet. Collaboration and accountability will keep the project moving. Strictly adhere to agile methodology when conducting these stand-ups.

    So many of us get mixed up between a status update and stand-up; there are glaring differences and each has their own purposes.
  • Do targeted project update sessions with execs. They are paying and they need to know. A weekly/bi-weekly project update session that is separate from your every day working sessions can save a lot of time for a lot of folks. Be transparent in these sessions and ask for resource
    help as soon as you see the need. Be ready to justify decisions/information with data.
  • Identify your sidekick who will things rolling in your absence. This is important in any reasonably large project.

3. People: Attitude and aptitude are equally important. Identify teams to divide and conquer.

  • Build and announce the project team with right folks from business and technical teams as soon as possible. Members need to be able and willing. Identify your key stakeholders on day 1. Who are the execs to be part of steering committee? Publish the functional org chart with proper backups in place.
  • Keep building relationship with folks in multiple teams. When going gets tough, people will go above and beyond for you. You’re going to need help from people you’ve never met.
  • Solicit feedback frequently from your team and adjust accordingly. Communicate expectations and boundaries. Don't be afraid to make seemingly hard decisions for the sake of project's success.
  • Know your project team well. Everybody has their strengths and weaknesses. Get to know them and be sure to let them know you. Use the knowledge to mitigate risks and resolve issues. 
Those are some of my lessons learnt from a fairly large data integration project. Don't forget to leave comments to share your thoughts.

Comments

Popular posts from this blog

Testing PDF forms with merge code fields - let's just build a tool

Dynamics CRM implementation: lessons learnt

Moving data? Integrating systems? Right ETL tool is your best friend