Comparison of Small Project vs Major Programme

Comparison of small project vs major programme. Working on a large project, perhaps partnering with an enterprise level Systems Integrator (SI) can be challenging and rewarding in equal measure. Basic project management principles will always apply in terms of the solid identification of up front end goals, and tracking progress will help get you across the line with sanity (and budget) intact, but here we will discuss what happens when you take a relatively simple Watson Marketing implementation and then scale up to System’s Integrator level.

With project requirements, what are your end goals? These should be clearly laid out and any requirements that contain the words “etc.” or “and so on” or similar should be called out at the start. Strict requirements will let you scope the project clearly. Ultimately you want all parties to be happy to signoff the work but keep an eye on those NFRs (Non-Functional requirements) that describe how a deliverable is going to perform rather than what it is going to do. The capacity for the project to go wrong if the foundations have been badly laid is almost limitless and review cannot be emphasised enough with a strong management team essential. When the subject area is particularly large or new to a customer then a helping hand up front in specification is never a bad thing.

A “normal” implementation of a handful of products may involve a statement of work upfront to say what you are doing, with a document at the end to confirm what was done/installed. As projects get larger the expectation to create more documentation will also grow and needs to be considered when planning your time. These documents will include Architecture, High Level designs, Low level design (or every interface potentially), ECR (Environmental change requests), CR (Change requests) – more on these later, test case creation, test evidence reports, project tracking and estimation, resourcing plans etc. Some days you may feel It would be good to actually make a dent in the actual implementation work rather than writing about it!

As a project continues, the subject of new requirements will inevitably arise. Sometimes it will only need the flick of a configuration switch but usually there will be effort from multiple teams and the impact must be assessed. While projects typically have some sort of Change request process in place, rarely have I seen one that builds in time to generate and size the CR in the first place, including time to review and sign off. I have been in situations where that process has eaten away at a month of the time reserved for other activities! Some projects might be large enough to absorb that level of activity but if not, contingency will soon start to vanish.

You will probably be working with multi-functional, multi-skilled teams. During some smaller implementations for example, you may be introduced to a couple of people in the IT department to help you with server and database. In the larger project world, be prepared to deal with a team for security, databases, network communications, systems architecture, standards and compliance and so on. Be ready to answer questions as to why this specific Watson Marketing component (coded maybe 6 months earlier) doesn’t satisfy the latest bleeding edge security measures. Work with these teams and use their experience because you may be trying to make the product set work in a way that has never been tried before! All of this will be against a fully auditable process of planning documents, ECR and justification/security exception reports. Sign-off requirements could come from almost any direction.

One area that I have found to have almost endless capacity to catch you out is around testing. The old way of testing a Unica (Campaign) delivery for example, could probably be summarised as, switch it on, can I create a flowchart? Yes – job done. More so than ever, and particularly on enterprise level projects you may now be faced with the prospect of working with a dedicated test team. Important considerations here include: are they skilled in the tech and if not how do we get them that way? Do they have enough knowledge to create and execute meaningful test cases or are you expected to contribute? Do you have enough knowledge around the various phases of testing that you could be asked to contribute in including Smoke, Unit, ST, SIT, regression, load or performance, penetration, non-functional, disaster recovery to name but a few? How will testing be carried out across a multi-environmental architecture and particularly if the project has been carved into multiple phases so that a test on a later phase must not interfere with a deliverable already in production? What will be the migration process (particularly If a component doesn’t lend itself to ease of migration for the build content). Despite all being perfect practitioners, have you allowed time for any defect resolution?

UAT, User acceptance testing is yet another level of complexity. Again, are the users skilled enough to complete or create the positive and negative test cases from the upfront requirements? Will you need to bring forward training at a risk of having to run through refresher courses when you eventually go live? What will your involvement be throughout and for how long? Ensure that you help steer the testing away from out of the box functionality!

Once the project (or phase) has been delivered, the next stumbling point could be the support team. The questions here are similar for the testing team, mainly around capability and testing but the underlying skillset will be different. On a longer project, they will probably be onboarded relatively late in the process but it is unlikely that they will have the right skills mix required to support the wide array of components that form Watson Marketing. Finally, have they, and you been considered for a post go-live warranty phase?

Time passing on a longer project will also introduce upgrade concerns as new versions of the software become available, particularly if external factors have introduced unexpected delays. If there is an agreement to keep the products upgraded to within a number of versions, you could find that there is an unbudgeted activity required to keep within those boundaries before you have even managed to go live. Even if you do not have such an agreement in place, a well-placed security bulletin email announcing a product vulnerability may prompt a request to update. When your environment is installed across 30+ servers across multiple sites, this becomes no small undertaking.

In summary, try to know what you are getting yourself in for, where your time will vanish and how you will keep activities to those agreed but of course ensuring you know what the definition of agreed is! Nail down the scope and don’t allow it to creep. The longer the project, the greater the challenges that will come everyone’s way but equally you also have the room to breathe, shuffle activities around and reprioritise to minimise the impact.

The details above are a summary of most of the things that I have found can cause a problem throughout a large program delivery. Discuss upfront with the project management team, ensure you have sufficient time built in to the planning and communicate with them throughout. The chances are that there’s a whole team of people dedicated to making problems go away!

Happy implementing! For more information please contact us!