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