Consulting & Business Development Handbook

How we approached technology consulting and business development: analysis, strategy, infrastructure, funded programmes, public tenders and practical digital transformation.

This handbook is part of the Dianthos Web Engineering Handbook and reflects work with organisations of different sizes, mainly in Greece, from 2003 onwards.

← Back to the Web & IT Handbook overview

The role of consulting in web & IT projects

Consulting was not about producing long documents; it was about helping organisations make better decisions around technology and digital processes. The focus was on alignment between tools and real work.

In the Dianthos approach, consulting typically involved:

  • Understanding how the organisation actually operated day to day.
  • Clarifying which problems were genuinely technological and which were organisational.
  • Translating needs into realistic projects and specifications.
  • Accompanying implementation rather than only designing it on paper.

The goal was to avoid both under-investment in critical areas and over-investment in systems that would remain underused.

Analysis of needs & technology strategy

Before recommending any solution, we invested time in understanding processes, constraints and objectives. This was often the most valuable part of the work.

Typical steps in needs analysis

  • Mapping key processes: sales, service, logistics, administration, communication.
  • Listing current systems and manual workarounds.
  • Identifying bottlenecks, duplicated work and recurring errors.
  • Clarifying priorities: what must improve now, what can wait.

From analysis to strategy

  • Defining a small number of concrete technology objectives.
  • Selecting areas where digitalisation would have measurable impact.
  • Planning projects as manageable phases rather than a single large initiative.
  • Ensuring that each proposed step had a responsible owner inside the organisation.

A simple, written technology roadmap, even on a few pages, often provided more clarity than complex diagrams.

Infrastructure, equipment & systems planning

Many projects started with basic questions: which hardware to keep or replace, which servers or hosting to use, how to structure networks and backups.

Areas we evaluated

  • Workstations, laptops and mobile devices: age, suitability, maintenance status.
  • Local networks and internet connections: reliability, security, capacity.
  • Servers and hosting: on-premise, shared hosting, VPS or other arrangements.
  • Peripheral equipment: printers, scanners, backup devices.

Planning principles

  • Choose equipment that is sufficient and serviceable, not unnecessarily complex.
  • Standardise where possible to reduce maintenance overhead.
  • Document network and system configurations for future reference.
  • Include backup and recovery in the plan from the beginning.

Infrastructure decisions were made with a medium-term horizon, usually three to five years.

Telecommunications & vendor management

A significant part of consulting involved reviewing telecommunication contracts, services and vendor relationships. Small changes often produced meaningful savings or reliability gains.

Telecoms analysis

  • Reviewing phone, mobile and data contracts against actual usage.
  • Checking invoices for underused services or overlapping plans.
  • Comparing offers from alternative providers where available.
  • Assessing quality of service and support in practice, not only in contracts.

Vendor management

  • Clarifying responsibilities between internal teams and external suppliers.
  • Setting simple service expectations (response times, escalation paths).
  • Keeping basic records of interventions and incidents for each vendor.
  • Avoiding dependency on single individuals without documentation.

The objective was to have contracts and partnerships that matched real operational needs, not theoretical maximums.

Funded programmes & investment planning

In the Greek context, many digital projects were supported by funded programmes (for example ESPA). Consulting work often included helping organisations align real needs with programme requirements.

Typical activities

  • Clarifying whether a programme was appropriate for the organisation’s stage and plans.
  • Translating business needs into eligible technology investments.
  • Preparing technical sections of proposals and required documentation.
  • Coordinating with accountants, consultants and suppliers where necessary.

The emphasis was on designing projects that would remain useful after the funding period, rather than focusing only on eligibility.

Public tenders & e-government participation

For organisations working with the public sector, participation in public tenders and use of e-government platforms became an important area of practice.

Support areas

  • Understanding the structure and requirements of specific tenders.
  • Preparing and organising technical documentation for participation.
  • Managing digital signatures and secure document exchange.
  • Using electronic tender platforms and public portals correctly.

Consulting in this field focused on reducing errors, meeting deadlines and creating reusable internal procedures for future participations.

Project governance, documentation & risk management

Even modest digital projects benefit from simple governance structures and written records. This practice reduces confusion and improves continuity.

Governance basics

  • Assigning clear roles: sponsor, project owner, technical contact.
  • Defining decision points and approval steps in advance.
  • Keeping a concise project log: key decisions, changes, issues.
  • Agreeing on how scope changes will be handled.

Risk management

  • Identifying critical dependencies (people, systems, suppliers).
  • Planning simple contingency measures for likely problems.
  • Testing backups and recovery procedures before they are needed.
  • Avoiding single points of failure in knowledge and access.

Documentation did not need to be complex; it needed to be accurate, accessible and maintained.

Change management, training & adoption

New systems rarely fail for purely technical reasons. They fail when people do not understand them, do not trust them or cannot fit them into their daily work.

Supporting adoption

  • Involving key users early in the design and testing phase.
  • Providing targeted training focused on real tasks, not only features.
  • Creating simple reference guides and checklists for common workflows.
  • Establishing a way to collect feedback and adjust configurations after launch.

Consulting work here overlapped with the Training & Education handbook: the objective was to make new tools genuinely usable, not only installed.

Evaluation, iteration & long-term perspective

Once a project was delivered, consulting did not end abruptly. Periodic review helped ensure that systems and processes continued to serve their purpose as conditions changed.

Evaluation practices

  • Comparing initial objectives with observed results after an appropriate period.
  • Collecting feedback from users and customers, not only from management.
  • Identifying which processes improved, which remained problematic and why.
  • Prioritising minor adjustments versus major redesigns.

Over the long term, a sequence of well-considered, incremental changes often proved more effective than rare, large-scale overhauls.