Blog

Our vision is to revolutionize and automate the loan servicing workflow of the global financial community.

Delivering Successful Projects

Project

We have supported many projects in our 50+ year history. We know there is a lot of internal pressure on stakeholders to guarantee that a project meets its targets for both the go live date and budget. In this article, we will share the following best practices to ensure a successful project delivery:
  • Properly define internal requirements and project scope.
  • Adequately staff the project.
  • Create an achievable project plan.

  • Properly Define Internal Requirements and Project Scope

    This is the most undervalued project phase. It is also the one in which most project managers and stakeholders allot an insufficient amount of time and attention. Why? Because we all want to see action taken and not get stuck at the planning stage. This simple but critical phase sets the baseline for change control. It allows you to communicate resource needs, costs, dependencies, gaps, and timelines more accurately. In addition, it is the launch point for your subject matter experts to start understanding the nuances between their current and new applications. A key to gathering requirements is understanding the methodology with which the software will be implemented. Common options include:

    Like for Like – The client has the same functionality on Day 1 as they have today with acceptable changes. Key risks:
  • The temptation to make your new software system behave like the company’s current software system. This can lead to unnecessary custom enhancements which drive up costs and delay timelines.
  • Powerful features of the new software will not be utilized using this methodology

  • Out-of-the-box – The business accepts changes to processes as needed to accommodate application functionality. Key risks:
  • Key personnel may be reluctant to learn new processes required from the software.
  • For this method to be successful, strong project sponsor involvement with an intimate knowledge of the current line of business processes will have to be in place.

  • Blended - This method involves accepting the core features of the new system while utilizing configurable functionality to maintain the culture of your company that makes it special. Companies should take as much out of the box functionality as possible while also maintaining whatever edge they feel like they have in the marketplace. Key risks:
  • Scope creep as new features are discovered.
  • Project delays are due to slow decisioning and inconsistent direction.

  • What is a good business requirements definition? It should be a document detailing the following:

    Current functionality – Document your internal processes. How do things get accomplished? Often such processes have not been looked into for years, if not decades.

    Critical functionality – Determine early what can be sunset and what can be Phase 2. If there are new processes your company desires, or additional processes your new software can facilitate, are they all an absolute requirement for day 1?

    Updated functionality – Provide descriptions detailing how the new application supports the functionality.

    Gaps – Identify gaps as early as possible. This helps implementation teams plan for needed custom enhancements or new business processes as part of an installation.

    Dependencies – Determine what must be in place for key functionality to work. This includes an enterprise architecture of how data will flow between applications within the company.

    You are now ready to build a draft project plan that allows you to assess your resource requirements, potential costs, timelines, dependencies, and risks more accurately. For example, if timelines are the highest priority, you are better positioned to make decisions that meet those constraints. When building a draft project plan remember to:
  • Move non-critical functionality, nice-to-haves, to Phase 2.
  • Leverage application base functionality vs custom enhancements.
  • Add resources where positive impacts can be realized.
  • Manage project expectations.

  • Adequately Staff the Project

    You have thoroughly documented the Day 1 requirements. Scopes for development efforts are in process. Like most projects, before you defined the project scope you were given a target date for implementation. Now the question is, can you meet it? You need the right number of resources with the right skill set.

    In our experience, most projects face one of the following problems:
  • Over-allocated resources – project resources assigned to multiple work-streams or multiple projects.
  • Inadequate resources – not enough people, missing skill sets, or both.

  • How do you accurately determine your resource staffing requirements?

    Estimate the work effort for each project deliverable. Remember to include all steps, i.e., specs build, testing, re-work for missed or misunderstood requirements, retesting, weekly status meetings, etc. Determine the number of resources and number of hours per resource needed to complete each deliverable.

    Identify the skill sets needed to complete each deliverable. Know your dependencies and prepare a mitigation plan. Review your estimates with your project team. They know best what they can accomplish. Identify resources assigned to multiple tasks and work-streams. Overloading resources is a serious project risk.

    Once you know your task by hours, skill set, and work-stream, you will have a better idea of the number of resources needed to achieve your target date. You are now able to justify your recommendations to your project stakeholders. Typically, you will need either more resources or more time. The numbers, if done right, do not lie.

    Create an Achievable Project Plan

    You have confirmed your functional and technical requirements. You have solidified your project team. You are ready to finalize your project plan. Most of you already know how to create a project plan, so we will cut to the chase. If your plan is going to work, it should include the following:

    Task level detail – A good plan documents each step for each deliverable and the resource assigned to it. Hours for each step aren’t as important as duration. This will allow you to identify dependencies and risk points across work-streams.

    Dependencies – This should include task and resource level dependencies. You need to understand potential impacts if that key resource is missing.

    Account for the unexpected – No formula is perfect here. Sometimes this just takes experience. You need recognizable buffers throughout your plan. Things happen. Murphy’s Law rules. Other initiatives take priority. Resources leave or are reassigned. Development does not go as planned. Build those likelihoods into your plan.

    Critical path – Clearly document the critical path. Project stakeholders should understand the most important milestones and resources. Missed milestones and unavailable resources require corrective measures. This also allows everyone to focus on what is important.

    Risk mitigation – Document your risk mitigation plans and get agreement early in the process. How are you going to react if you miss key milestones, or your target delivery date is compromised? Can you add or reallocate resources? Can you adjust other tasks or deliverables? Can you delay the go live date? Can you move some planned Day 1 functionality to Phase 2? Preparation here is critical when things do not go as planned.

    The best project managers prepare for the worst and communicate mitigation plans to their project teams. If you would like more insight or have any questions about Shaw’s loan servicing software, email us at solutions@shawsystems.comor call us at 713.782.7730.