This checklist helps you evaluate your organization’s readiness to run a development project efficiently.
Solid enterprise architecture practice in place
A solid enterprise architecture practice offers significant advantages to the project:
- Current processes are well-documented and well-managed. Process owners are known and are ready to help allocate subject matter experts to participate in the activities.
- The current application landscape is well-documented. System owners are known and are ready to help coordinate test and deployment activities.
- The infrastructure and currently used technologies are well-documented and well-managed. Experts are available and ready to advise the project.
- Procedures for handover to operations are well-documented, and operations specialists are ready to advise on the project.
A weak or no enterprise architecture practice means that the project faces an uphill battle on all fronts. Much more business analysis work is necessary to uncover the business model and all its key elements, like processes and resources. Additionally, the project must assess the current infrastructure and identify existing applications.
In short, the project needs to develop a complete picture of the prevailing enterprise architecture to successfully design, develop, and implement a well-fitting solution. Time and budget limitations may not even be the biggest challenge – the organization may resist participating in establishing the required understanding of the enterprise architecture because it highlights inadequacies in how the business has been managed so far.
Lean development process in place
A lean development process enables the project to work faster and with more precision:
- The project team knows exactly which work products to make, and templates, guidance and examples are readily available.
- The project’s stakeholders can easily understand the project team’s plans because information is structured in a familiar way.
An inadequate development process forces the project team to spend excessive time on bloated or meaningless work products.
The lack of a development process forces the project teams to invent one on the fly, which slows down the pace and steals focus from the development of the solution. Additionally, the team will struggle with stakeholders who will have diverse opinions about the process and its deliverables.
Proper tooling in place
Having the right tools available helps the project team solve problems more easily, capture and share information efficiently, and build deliverables more quickly:
- Cloud-based documentation and task management tools are easy to share with everyone involved in the project, inside and outside the organization.
- Development work requires diagramming and writing tools to create the necessary work products.
- Feature-rich development environments speed up coding and debugging.
- Continuous testing and deployment reveal bugs early.
Poor tooling slows down the project team’s pace and will likely result in poorer documentation.
Warning signs
Sometimes you can’t immediately tell if the above prerequisites for good project readiness are met. And when asked, managers will often claim that they are, even when they are not – either because they don’t fully grasp the concepts themselves or simply don’t want to go on record admitting that management isn’t interested in them. Regardless, here’s a list of warning signs that most likely indicate poor project readiness.
Nothing about enterprise architecture or development process on the intranet
A solid enterprise architecture can only exist if it’s well documented and readily available to everyone in the organization at all times, which usually means it’s published on the intranet for easy and unrestricted access.
If you can’t easily see anything on the intranet, chances are it simply doesn’t exist. Most likely, it also means that the organisation will resist your project’s efforts to establish the necessary understanding of the actual enterprise architecture in which the project’s deliveries will eventually be implemented.
Obsessive mindless misuse of PowerPoint
PowerPoint is the right tool to present simple clear messages. It’s not the right tool for creating work products like business cases or status reports etc.
Organizations with no or a weak development process often rely on PowerPoint presentations as work products that a project needs to submit to leaders to get their ideas and funding approved. Throughout the project, project managers and other key members create endless presentations that supposedly document the outcome of their work.
The problems with using PowerPoint are many:
- Presentations with lots of content like text and drawings quickly become messy, and are difficult to edit.
- When shown on big screens in meetings, the audience finds it hard to read the text. This steals the attention from the presenter, which further blurs the message.
- PowerPoint makes an awkward reading tool compared with Word or a PDF-reader or reading a page in a website.
Believing meetings solve anything
Many organizations immediately call for meetings to solve any obstacles. But meetings should only be held as work meetings where participants collaborate to produce work products that are part of the development process.
Any other type of meeting always ends up being attended by far too many people, most of whom can’t really understand the obstacles or contribute to solving them effectively.
Someone also always ask for meeting notes to be shared after the meeting. But writing anything down during a meeting should be content in a work product. Otherwise it’s just notes about what should be done – namely producing meaningful work products later.
And someone always object to something in the meeting notes, which means more time is wasted on correcting and resending edited notes, which most attendees won’t read anyway.
Using email and chats to discuss issues
Lacking suitable tools or just being lazy, many people randomly choose to ask important questions or share key information in emails or in online chats. They even jump back and forth between emailing and chatting during longer online conversations.
The downside to this behavior is that it becomes difficult to rewind back to the start of a conversation and follow the related exchanges chronologically, and it and important details end up being overlooked and forgotten – causing grief further down the road.
Management’s reluctance to invest in professional workgroup solutions and task management tools force people to fall back on this undesirable practice. But tooling doesn’t change people’s habits, so proper introduction and training in their use is needed, and ideally immersed in the development process.
Scattering documents and other files everywhere
Many organizations lack the tooling most supportive in development activities. Instead, people put their work products (documents and other files) randomly on their local disk, shared file servers, SharePoint, various OneDrives etc.
Since work products serve as input to subsequent activities in the development process, it’s important that they can be easily and quickly located. Having to scavenge after files in deep counter-intuitive folder hierarchies in SharePoint more or less equals just putting them directly in the trash bin.