Thursday, April 21, 2016

10 Ways to Screw up an IT Project with Technology Madness



Whether an IT project is of development, integration or transformation type, Technology Selection has always been a critical activity for it. It is critical because the technologies selected are used during the entire life cycle of the project and remain as the main drivers for successful completion of the project with desired Quality of Service (QoS) of the product. This activity requires an intense study of the business, functional, non-functional requirements, expected QoS, user requirements and the existing system if any.
Usually this process falls in the area of the technical leads or architects. Selection of right kind of software, technologies, frameworks and tools becomes a boon to a project, provided you have right hands to operate these instruments efficiently. However the main objective is to deliver high quality (QoS) software with desired outcome which can never be compromised during this process.


There are well-known project management issues to screw up projects which are the subjects of project management experts however technology selection is entirely a subject of the techies. Gil Edelman provided a nice and brief overview of technology selection process in his article “How to Choose Your Tech Stack” (http://svsg.co/how-to-choose-your-tech-stack/). Primary factors that drive the technology selection process are
·         Scope of Project
·         Functional / Non-functional requirements
·         Budget for Licenses
·         Availability of Skills / Experience
·         Political influences
·         Strategic vision & Management Buy in
There are very few technical pros-cons that really matter. For example, PHP, C#, Python and Java – all of them work perfectly. The choice is usually driven by budget, strategic vision, political reason or available experience more than anything else.
Quality standards e.g. ISO or CMMi ensure that things are done properly e.g. Right Design, Right Requirements, Right Budget, Right Testing and Right Attitude etc. These standards can ensure whether the process of software manufacturing, testing and delivery are done properly or not. The quality parameters of the actual software system (e.g. Quality of Service) and technology are not the primary focus for them, while Quality of Service is the primary focus area for technology selection process.
However there are situations where wrong technology selection can be disastrous. Having all cutting edge technologies together doesn’t always help projects to fly especially when the technology is under research and experimentation.


1.     Poor Statement of Work
When no one is sure about what needs to be accomplished, things start to get fragile from the beginning itself. One of the key ways to screw up a project is to avoid creating a roadmap, definition of project requirements and expectations of all stakeholders in a documented format at the beginning of project and get approval from all stakeholders. This is a common approach as mentioned by Jennifer Lonoff Schiff in her article “15 Ways to Screw Up an IT Project” (http://www.cio.com/article/2384088/project-management/15-ways-to-screw-up-an-it-project.html).


2.     Lack of Clarity on Requirement

When functional requirements of a system under development are not understood well, we can’t decide whether a web server or portal server (for example) is required. This is a typical decision point on whether an application is going to be offered over the web or not. There are several basic questions and checklists which may drive us to different kinds of software types e.g. Infrastructure services, Network Services, Messaging Services and Security Services etc.
An application connecting with external systems raises more questions on which transport techniques, protocols and security measures to be used, which might drive us toward an ESB or set of connectors or adapters.
If the business logic is expected to be configurable such as a rule, a business rule engine is helpful.
Certain questions usually get their answers from the Application Architecture of a system. TOGAF has rightly depicted the dependency of Technology Architecture on Application Architecture (http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap12.html). Without diving deep into the functional requirements, arriving at decisions in these areas is next to impossible.
Apart from functional requirements, identification of Quality of Services (QoS) and non-functional requirements play a critical role in technology selection.
The top most priorities of systems like Google search, Twitter, Facebook have been speed, parallel processing, security and processing of gigantic volume of data. If we have similar requirement, technologies like big data and faster real time processing can be considered, otherwise it is an overkill of effort such as putting a Jet Engine in a bicycle.





Finally the end user requirement means a lot. I have seen systems with full functionality being rejected by users due to the lack of user friendliness. A study of user communities, their requirements, ease of use and comfort helps greatly in deciding whether to go for computer, tablet, mobile or other devices. Sometimes experienced users with mainframe backgrounds might not like the idea of playing with their mouse on a beautiful web responsive GUIs. Popular user interfaces can be a way to screw up the success here. Managing comfort and expectation is the key to success.


3.     Too Many Stakeholders

Projects with multiple stakeholders (including customers, management, end-users and technical architects or leads) really need the best of luck to survive. In this situation applying technical governance is a big challenge. Starting projects of this type without a technical governance framework is the surest way to screw up.
Presence of multiple stakeholders usually requires the technology stack to be decided and reviewed by many.
Stakeholders with their various backgrounds and experiences possess different perspectives and try to help out during technology selection process by contributing their thoughts. Managing and convincing them efficiently can obviously save the project from being doomed. This is a sensitive task which should be handled with care by considering the sentiments, interests, importance and political angles. TOGAF nicely describes Stakeholders Management as one of the key areas (http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap24.html).

4.     Personal Aspirations & Technology Madness 

Developers always enjoy learning new technologies (I am confessing). Most of us are or were developers. Using young developers’ mindset and perspective during technology selection is another way to screw the project. Learning new technologies for fun and applying them in real project deliveries have different risks involved. Not all cutting edge technologies are required to achieve desired outcome from the system under construction. Sometimes they might appear in your nightmares when you are suffering from lack of support and newly reported bugs. 

In 2010, Twitter’s search engine was re-developed using Apache Lucene by replacing MySQL. Again in 2011, they shifted from Ruby-on-Rails to JVM for better performance and scalability. So analyzing the pros-cons, finding out the availability of support and forums are mandatory activities before jumping for any new technology. After all, the customer will not wait till you find a new solution or fix a bug in your tech stack. Therefore technology madness is a strong driver behind immature decisions.



5.     Poor Communication 



Mr. Architect has defined all technology layers with latest technology components, discussed in meetings and prepared slide decks to share his thoughts. But designers and developers are not sure how to use them in code.
Well I might love to use Spring Framework annotations for dependency injection (DI) to avoid the pain of defining the beans in appContext.xml but another developer might not have that knowledge, hence we end up with some beans defined in xml while some are auto wired with annotations in the code. Eventually the team which gets to manage the code later will be in a soup.
Similar situations can arise while using a message oriented middleware (MoM). I am using my SOAP objects over HTTP transport while my friend likes JSON over HTTP. Therefore, defining a descriptive document with all areas covered is the primary task of an architect. Apart from that, the architect should hang around with the developers to ensure the architecture standards, patterns, technology best practices are being followed and enforced properly. 


6.     Lack of Skills & Experience

A very crucial point, lack of skills and required experiences to define and use technologies can work as a knife through the butter, when comes to screwing up a project. This applies not only for developers but also for the architects. An architect without knowledge of latest technologies and their impact on the target system is really helpless in technology selection process. Upgrading skills and knowledge can be a savior in situations like this.
The architect must provide enough rationale and logically proof the suitability, capability and applicability of the selected stack with respect to the requirement of the system under construction. She should also list out all architectural goal and constraints (aligning with the technical vision and strategy) and show how the selected stack is supporting the goals and constraints.
Lack of developers with required skills is the most critical issue that can easily screw a project. Proper screening, recruitment of technical members and training them can help on this to a large extent, however to touch the seventh heaven, experienced professionals are your only instruments. This is where the technology stars and heroes are born to save the project.

7.     Compromising on Quality of Service
Quality of Service (QoS) is a significant factor which drives the technology architecture of a system, especially at the age of component or service based architecture. The parameters of QoS e.g. Performance, Availability, Scalability, Security, Serviceability, Reliability, Maintainability, Evolvability, Survivability, Adaptability and Reusability etc. are considered as the measure of a highly efficient and robust system.
Decisions to apply architectural styles such as SOA or Microservices, architectural and design patterns can help in reusability, serviceability and adaptability.
Cassandra database is failsafe, highly scalable, specialized in fast insertions, however query executions with joins (such as in SQL) is not a sweet spot for Cassandra. For new queries, you might need to copy data to a matching data structure on a SQL database. Shifting design paradigm from a relational background to the world of name/value or column families is not an easy job.
To avoid bumps ahead, sometimes the QoS of the system is compromised with the technologies or tools in our comfort zone. Usage of legacy technologies sometimes restricts the system to leverage improved features from the cutting edge technologies, speedy development life cycle.
On the other hand, using all latest technologies with lack of experienced developers and lack of support can surely screw up the maintainability of a project.


8.     Technology Life Cycle

The architect can easily ensure the birth of a system with a bunch of outdated technologies by selecting the tech stack with technologies which are out of life (such as the legacy ones from history which can only find few old hands e.g. Visual Basic, Power Builder, COBOL, Sybase etc.).
On the other hand, selecting the alpha, beta, early release or latest versions of software tools can put the system in great risk due to lack of support and unknown bugs.
Using the previous version of software than the latest can be a safer option. You can check out the defect lists from the release notes before doing so.

9.     Lack of Compatibility with Strategic Vision

Business or enterprise strategies are usually established as a result of political influences, business vision, governance policies and achieve specific business targets such as profitability, cost cutting, promotions etc. Technology strategies are driven by the enterprise strategies. In fact, most of the software development, transformation, integration and implementation projects are kicked off as per business strategies and plan. Most of the large scale transformation, migration, rationalization and modernization projects are aids to cutting cost on maintenance.
One will surely not migrate to an IPv4 network when the strategic vision demands for a rapid growth preferably to an IPv6 network. 

Selection of right kind of technology stacks is a sensitive issue. It requires study of entire enterprise landscape, business processes, features, interfaces and standards to be able to define the target technology stack so that redundant applications are decommissioned or consolidated to the strategic stack. Poor decision making on tech stacks takes its toll hugely on these projects.

10.     Budget and Cost



The budget and cost of software licenses and cost of human resources are two major factors that influence the technology selection process. For example, Open Source software is a popular instrument for cost cutting however maintaining them can be a pain due to lack of managed services. We need to arrive at an optimum balanced figure between cost and maintainability here.

Finally, it is suggested considering the Technology Selection process with required care by realizing its importance and effectiveness at the beginning of IT projects. It should be initiated by identifying significant factors, drivers and stakeholders followed by a proper study and evaluation of technologies. Preferably performing proof-of-concepts of technologies (once decided) can give us better peace of mind.



No comments: