We’re at a pivotal moment in the publishing industry. The market has changed! As a result, publishers are actively seeking new avenues to grow revenue through digital products and services.
Digital media is now essential as publishers search for ways to leverage additional value from content. As part of this shift, publishers are increasingly looking to software vendors to help them take advantage of new opportunities.
It’s a smart move, but it’s not without challenges. The internal infrastructure at most traditional publishers is still rooted in a 400-year-old tradition—a unique blend of creativity and a linear production process. Software development on the other hand is at the cutting edge and constantly evolving.
With different traditions and ideas about how things should be done, software vendors and publishers often struggle to align their processes and goals, leading to poor outcomes or missed opportunities.
In our careers with Typefi, my colleague Marie Gollentz and I have worked with a wide range of publishers to implement automated publishing software. Marie has served as Project Manager for hundreds of implementations, and I’ve been in the trenches as a Solutions Consultant for at least as many. Throughout those projects, we’ve clearly seen what works and what doesn’t.
In this guide, we’ll reveal what all the most successful projects have in common and explain how you can leverage these insights for your organisation.
Assemble the Ideal Project Team
The most important part of any project is the team of people driving it. Bringing the right people on board can mean the difference between success and failure.
As publishers’ products morph into various digital versions, the roles required to build them will evolve. Traditional publishing and IT roles must work together to achieve successful outcomes.
We see a few roles as major keys to success—each is responsible for a specific and important piece of a given project. You don’t need to have these exact roles at your company, but it’s helpful to understand why these roles are important to the success of a software project.
Executive Sponsor
Also known as the “champion” or “visionary,” the Executive Sponsor has ultimate responsibility for the project and will report progress to the board.
Their job is to clearly define the purpose of the project, its objectives, and how it fits into the company’s overall product strategy. The Executive Sponsor must also ensure the project will provide a return on investment.
Additionally, the person in this role should be able to push through organisational obstacles, make resources available, sign off on the budget, and provide guidance for difficult decisions.
Regardless of their exact title, the person who fills this role should be an executive with the authority to make significant decisions.
Architect
The Architect is the bridge between the project’s business objectives and the technological infrastructure required to make the project a success.
Their role involves looking across the whole organisation and determining the touch points for information across departments (editorial, design, sales, production, etc.). At each touch point, they must consult the relevant internal stakeholders to confirm their technological needs. For larger organisations, this might require the assistance of a business analyst to do a comprehensive audit.
In addition to managing IT infrastructure, the Architect should have a thorough understanding of the publishing process including content formats and structure, data conversions, API protocols, cloud platforms, and various staging and production environments.
Project Manager (PM)
The name says it all for this role—the Project Manager is responsible for managing the team and keeping the project on track.
The PM should have expertise in managing people, resources, timelines, and budgets. They should also have a thorough knowledge of publishing processes and how to manage software implementations. The PM should be able to speak the same language as the software developers in order to clearly communicate the publisher’s objectives.
Implementing software is a very different undertaking from developing and publishing content. To bridge this gap, a PM who understands change management will help ensure teams are well-prepared and aware of their roles and responsibilities.
We recommend contracting a PM for the duration of the project if you don’t have someone at your organisation who can fill this role. It will help keep the project within scope and on schedule, and significantly increase the project’s likelihood of success.
Product Owner (PO)
When a publisher begins offering digital products and services, the need will arise for a dedicated role to ensure products continue to evolve while providing value to the users and revenue to the publisher. The Product Owner is this new role.
The PO continually reviews data from online platforms, stakeholder requests, user feedback, and IT infrastructure analysis to determine the impact of digital products. They use this information to guide content priorities and define future strategies.
The PO also collaborates with the PM to develop an implementation plan for new software projects. They work together to identify and prioritise issues such as bugs, feature requests, user experience improvements, and system optimisations.
Plan ahead to manage change
Software projects often mean significant changes in how people work. Resistance to change is normal, but it can be challenging to overcome. A well-crafted change management strategy can help.
A change management strategy should explain why the change is necessary and how it will benefit the users and the organisation. It should also address any concerns from your staff.
A collaborative approach to change will minimise the stress that comes with it—check out our approach to change management for some practical tips.
Communicate clearly and often
Regular communication between external and internal stakeholders is essential during any project.
It’s the most effective way to manage and track tasks, keep stakeholders abreast of developments, alert your team to any potential roadblocks, and maintain high-quality standards.
If a new issue is identified, it’s best to discuss it with your project team as soon as possible. Checking new issues against the project criteria will also mitigate the risks of scope creep, delays, and additional costs.
Clear and regular communication will provide transparency, build trust, grow confidence among your teams, and contribute to the project’s success.
The 5 stages of a software project
A typical software implementation project goes through five stages:
- Identify needs and set goals
- Scope and project plan
- Development and feedback
- User Acceptance
- Move to production, ongoing support, future development
Completing each stage as thoroughly as possible is crucial for the ultimate success of your project.
(1) Clearly identify your needs and goals to select the correct vendor
A project typically starts when a publisher recognises a need or business opportunity which drives a decision to look for a software solution.
The specific need or opportunity could range widely. Additional efficiency in print production might be needed to speed up time to market. You might need to use new formats to reach a wider audience, or you might need a better platform to distribute digital content. Or it could be all of these!
Regardless of your specific needs, you should try to define them as clearly and explicitly as possible—this will become the scope of your project.
Once a need has been recognised, you should create a list of potential vendors and narrow them down through rounds of demos and conversations with each.
Once a vendor is finally selected, the project can begin.
(2) Partner with your vendor to establish the project scope and plan
Before any work begins, your chosen vendor should hold a series of meetings and “discovery” workshops with the project’s key players.
During these meetings, the vendor will work to understand your processes, confirm requirements related to the project, and discuss the desired outcomes. These meetings will help the publisher ensure its business goals are aligned with what the vendor can provide.
During this stage, the various project roles have some vital tasks to complete:
- Architect: provides the vendor with detailed information on the system design and where the solution should fit with existing infrastructure. This includes any other systems (CMS, DAM, e-commerce platforms, cloud services) that need to be integrated to ensure uninterrupted business and scalability.
- Project Manager: works with the vendor to plan the project from start to finish. They liaise with internal stakeholders and the vendor to confirm specifications, estimates, timeline, budget, acceptance criteria, and communication channels.
- Product Owner: further refines the scoped requirements to ensure optimal user experience for both digital and print products.
As this stage progresses, the vendor may suggest alternatives based on their experience in software development. The vendor is the expert in what they do, so it pays to listen. Their recommendations might save you time and money!
Once the bulk of the conversations and resulting decisions are completed, a project roadmap will be created. The roadmap contains all the tasks, timelines, and outcomes for each project stage. This helps keep the project on track and allows for an iterative process.
You should also discuss the acceptance criteria and test cases for your project during this stage. These should be as comprehensive as possible and should be part of the project scope. The test cases you define at this stage will be the reference used to determine if the project features work as expected. More on this below in phase four.
(3) Provide feedback during development
For smaller projects, development could take place all at once. But for larger projects, development is usually broken down into shorter “sprints” with specific goals and testing after each sprint.
For example, an initial sprint might focus on developing a sample to test a transformation of content from one format to another. Testing during this sprint will ensure that the transformed content meets the standard for integration into another platform. Additional sprints with larger samples are then set to ensure all variations and edge cases are considered.
At the end of each round of development, feedback from the publisher is documented and translated into specific tasks for further development.
Whichever approach is taken, it’s important that the project stages are followed—these will ensure the efficient completion of the project.
(4) Be thorough with testing to ensure no surprises later on
Once development is completed, it’s up to the publisher to perform User Acceptance Testing (UAT) in a staging environment.
A staging environment is a parallel environment that mirrors the production environment but is totally separate. That way, if anything breaks, it will not affect the production environment.
To test your project, your team will use the test cases you defined during the scoping phase. These testing scenarios must be documented and the associated data for each test must be identified.
Depending on the scenario, the data could be an existing publication, carefully crafted test content, or a combination of both. The vendor might also suggest smaller “unit tests” to rigorously test individual features.
Testing should replicate your eventual production process as closely as possible and include common tasks, edge cases, and variations to stress test the system.
In the early stages, you will likely uncover bugs or unexpected behaviour. This is normal—you want to find these issues now. It’s much worse to discover issues once the system is moved into production.
(5) Define clear channels for support and future development
Following acceptance, the next step is moving the project into the production system.
The move from staging to production is a gradual process. At this point, you should start running smaller jobs through the new system with the old system running in parallel as a contingency.
Questions will inevitably arise during this phase. That’s why you must establish a clear channel of support for stakeholders and users during the transition to production. This should include support from your software vendor and a member of your team who can act as a first line of support.
Ideally, your internal support person should already be involved in the project. They should take part in the test phase and have in-depth knowledge of the system. This can save time in resolving issues and build confidence within your team.
You should also expect your new system to continually evolve. Users and customers will identify new requirements as they explore what the system can do. It’s a good idea to maintain a communication channel with the software vendor to discuss new features and further development.
Change doesn’t have to be difficult
Change is normal, and so is our resistance to it. To succeed, you have to embrace change.
If you’re a publisher, I’m sure you’ve heard something like, “But we’ve always done it this way.” That’s not a good reason to continue doing something that doesn’t work! The only way we can grow, either as companies or as individuals, is to change. It’s just a part of life.
The good news is that in business, we can minimise the risks of change with thorough research and planning. We can define goals that we can only achieve by changing our processes, then we can find and implement the best solution.
Typefi is an automated publishing software vendor, and we follow this outline very closely when working with clients. We see resistance to change all the time, but ultimately it’s our thorough project management and the incredible benefits of our solution that win over the holdouts.
If you follow the steps we’ve outlined above, you’ll set yourself up for successful changes in your organisation.
Damian Gibbs
Solutions Consultant | South Africa
Damian started out as an apprentice typesetter over 20 years ago at a leading South African educational publisher, and from the start was curious about the opportunities that digital technologies bring to publishing. He transitioned to general market publishing and eventually became a service provider to local and offshore publishers covering a diverse range of publishing markets, all requiring varying workflows and output requirements.
Damian has extensive experience working with publishers to develop and support automated publishing workflows and transition from pure print to digital outputs such as web, e-books, and CMS publishing.
Marie Gollentz
Project Manager | France
Working closely with Typefi’s team of experts, Marie manages client projects to ensure they are successfully delivered and meet clients’ specific needs. Marie joined Typefi in 2016 as a Solutions Consultant and brings to her current role a wealth of experience in helping clients adopt the best solution to achieve their goals. In 2022, Marie achieved her Certified Associate in Project Management (CAPM) qualification. Marie is brilliantly trilingual in English, French and Spanish!