Projects drift when the goals behind them are vague, so delivery needs to be tied to your strategic goals. Oblytech’s Project Management & Business Analysis services provide the guidance you need to work through complex projects and streamline processes. We combine established methodologies with attention to your business needs, so that each project is planned and tracked against goals you agree with us.
We work closely with you to define project scope, create detailed plans, allocate resources effectively, manage risks, and work toward successful execution from start to finish.
We use Agile methods, such as Scrum or Kanban, to keep projects flexible, encourage collaboration and improve steadily throughout the project lifecycle.
We track project progress closely, identifying potential risks and roadblocks early on. We implement corrective actions to keep your project on track against the plan agreed with you.
Our business analysts work between business and technology teams, helping IT solutions line up with your strategic goals and the outcomes you need.
Many projects run for months with a sponsor who is also doing a full-time job, a technical lead who is pulled onto production support, and a steering meeting that rarely gets past the status colors. The project limps on, dates slip by a few weeks at a time, and nobody can say with confidence when the work will be finished. Adding a dedicated project manager and business analyst is one answer, but it is not automatically the right one. The question to settle first is whether the project is short of coordination, short of clarity about what it is meant to deliver, or short of decisions that only the sponsor can take. Each of those needs a different remedy, and a dedicated role fixes only the first.
The route suits a project with several business areas, a dependency on systems owned by other teams, or a budget large enough that an unplanned slip has a visible cost. It is less useful for a small change that one competent person can coordinate in a fortnight, and a full project office for that kind of work adds cost to a problem that does not call for one.
A plan built before the requirements are agreed is a timetable for guessing. The schedule looks precise, but each task rests on an assumption about what the finished system must do, and those assumptions tend to change once the first demonstration reveals a gap. Business analysis exists to make the assumptions explicit before they become commitments. It records what each user group needs the system to do, which rules govern a decision, which data must be present before a step can start, and which outcomes the sponsor will treat as acceptance.
The output is not a document for its own sake. It is the basis for the plan, the test cases that come later and the change requests that will otherwise arrive as surprises. A practical check is to ask whether a reviewer who was not in the workshops could read the requirement and tell whether a finished feature satisfied it. If not, the requirement is still a wish.
The live service description names Scrum and Kanban as options for iterative work. The choice between a predictive plan and an iterative approach is less about fashion than about how much the outcome is known in advance. The table below sets out the trade-offs that tend to decide the matter.
| Project condition | Predictive planning tends to suit | Iterative delivery tends to suit |
|---|---|---|
| Requirements | Stable, regulated or contract-bound | Likely to change as users see early results |
| Dependencies | Many fixed handoffs with external parties | Mostly internal, with frequent feedback possible |
| Funding | Approved as one amount for a defined scope | Released in tranches tied to working output |
| Risk of failure | Known and costly to discover late | Better exposed early through short cycles |
Many real projects mix the two. A predictive plan can govern the contract, the budget and the release dates, while the build inside it runs in short cycles. The mistake to avoid is adopting the vocabulary of one method while keeping the governance of the other, which produces sprints that report to a fixed-scope change board and then wonder why nothing moves.
Good monitoring is about early signals. Status reports that describe activity completed tell the sponsor very little. Useful reporting shows the trend in open decisions, the number of items waiting on a single person, the age of unresolved defects, the proportion of requirements that have been confirmed by the user group that will use them, and the gap between the current forecast and the milestone it was set against. Each measure should have a threshold that triggers a conversation, not a discussion at the next scheduled review.
Corrective action should be proportionate. A slip caused by a late decision is solved by getting the decision made, not by adding people. A slip caused by unclear scope is solved by re-confirming scope with the sponsor, not by working harder on the existing plan. Recording which kind of slip occurred is what allows the next project to avoid the same pattern.
Stakeholder management often appears as a list of names with an influence rating beside each. That list is a starting point, but the management happens in the conversations that follow. The useful questions are concrete: who will be unhappy with this design, what do they lose if it goes ahead, and who has the authority to resolve the disagreement? A business analyst who can state a disagreement precisely, with the options and their consequences, is far more helpful to a sponsor than one who smooths it over.
Users who will operate the system deserve their own channel. Their concerns about daily workload, exceptions and reporting rarely surface in steering meetings, and they are often the reason an otherwise sound build fails to be adopted after release.
Often a named owner, a short list of decisions and a weekly check-in are enough. A full project office is justified when several teams, budgets or contracts are involved at the same time.
The project manager controls the plan, the risks and the commitments. The business analyst controls the definition of what the plan is for. The two roles should check each other, and a project where one person carries both should say so openly.
Yes, and the first task is usually to reconstruct the requirements from the decisions already taken, the defects already logged and the conversations that produced them. That reconstruction often exposes the disagreement that is holding the project back.
No. Sponsors decide scope, priority and trade-offs. Project management makes those decisions visible and arranges them so the sponsor can make them on time.
A charter is the short document that tells everyone what the project is for and who decides. In the first month it should name the sponsor and the authority that sponsor holds, state the outcome in terms the business would recognize, list the groups affected, and record the constraints that cannot move, such as a regulatory deadline or a contract end date. It should also say how decisions are escalated and how long each escalation may take before it is considered stalled. Those last two items are the ones most often left out, and their absence is why a project can sit for weeks waiting for an answer that nobody had the authority to give.
The charter is not a substitute for the plan. It sets the boundaries inside which the plan is built, and it should be revisited whenever a boundary changes, rather than left in a shared folder to age.
The services overview lists the delivery routes on the site, and the IT strategy and planning route describes IT assessments, roadmap development and technology alignment, which are the kind of direction-setting that usually comes before a project starts. Organizations running ServiceNow can read the project portfolio governance guide, which looks at how leaders decide which work should enter delivery.
A project is finished when the people who will run the result accept it against criteria written before the build, not when the last task turns green. Project management and business analysis share that closing work: the analyst keeps the criteria honest, and the project manager makes sure someone is ready to own what has been built.
Acceptance criteria should come straight from the requirements. Each one needs a named person who can say yes or no, a way to check it that does not depend on opinion, and a rule for what happens when it fails. If a criterion cannot be checked by someone outside the project team, rewrite it before testing begins.
Handover is a separate step and is often skipped. Before the sponsor signs off, settle these points:
Operational readiness matters as much as the build. The support team needs to know what changed, the users need to know what to do differently on their first day, and someone needs to be watching the first real transactions rather than the test ones. Teams that plan this tend to find fewer surprises after release than teams that treat go-live as the end.
Close the loop on benefits too. A short review a few weeks after release compares what the business expected with what it sees, and it should record the gaps without blame. Those gaps usually point to a requirement that was never confirmed or a decision that was made without the people affected.
Validation by the business is covered in more detail in our guide to business-owned user acceptance testing. Testing practice more broadly sits under quality assurance, and ongoing ownership after release is the territory of application management.
The sponsor signs off, usually after the business owners of the affected processes have confirmed their own criteria.
It should be. Give it its own tasks, dates and owner, so it is not squeezed in after the budget has gone.
Before a requirement enters the plan on a ServiceNow project, decide whether standard features and configuration can meet it, or whether it needs custom development. That decision changes cost, test effort and who maintains the result after go-live. A requirement met by configuration is usually easier to carry through a platform upgrade. A custom build should be retested at each upgrade, so it should earn its place.
The working rule is to test each requirement in order. First ask whether a standard feature covers the process as the business runs it today. Second, ask whether a configuration change, such as a form layout, a business rule or a workflow, closes the remaining gap. Only what is left after both checks goes forward as custom work. The analyst should record which step settled each requirement, so the sponsor can see why a custom item is in scope.
The common trap is a requirement written in the language of the old tool. A sentence such as “the approval must look like the spreadsheet” describes a screen, not an outcome. Restate it as the decision the approver has to make and the evidence they need to make it. Often the standard approval handling answers that without code. Where the answer is still no, the custom item goes into the plan with its own owner and its own acceptance test.
Guardrails matter most when the people changing the platform are not developers. Citizen development guardrails set out who may change what. Agile teams building on the platform can follow the ServiceNow agile development approach, and ideas that compete for the same build capacity belong in the project portfolio management view. Check every standard feature named here against your own instance and release, because what exists and how it behaves varies by version and by what has been installed.
Guides from the Oblytech ServiceNow library that explain the practice behind this page.