A PROJECT MANAGER REQUIRES TECHNICAL KNOWLEDGE AND UNDERSTANDING.

1.???TECHNICAL KNOWLEDGE AND SKILLS

Because technical knowledge is so diverse, it is important to focus on relevant technical knowledge when discussing it. Technical knowledge refers to the ability to complete complex tasks.

Technical skills are sets of abilities or knowledge used to perform practical tasks in the areas of science, the arts, technology, engineering, etc. In most cases, the acquisition of advanced technical skills requires specialized training or education, which takes both time and resources.

The exact set of skills considered technical knowledge varies depending on the field of work.

There has been growing distinction between project management and technical project management. The core requirements are the same, managing the project plan, timelines, milestones, risks, resources etc. but a technical project manager brings technical knowledge and understanding to the project.

2.???PROJECT MANAGEMENT IS INDUSTRY INDEPENDENT BUT PROJECT MANAGERS ARE NOT

Project management is industry independent, the theory works in all kinds of industries. But project managers are not industry independent,they must have good technical skills in their field. Project managers must not only know how to operate in business and project environments, they must also be well acquainted with the focus of the project.

A project manager focused on functional projects generally won’t have the technical understanding required to make quick decisions and add valuable insights, however, they will have the core project management skills to put a robust project plan in place. If the project is complex, industry specific and requires industry knowledge, the core skills will be there but there will be a knowledge gap that most projects can’t allow for.

The advantage of the technical understanding is that they can properly assess and plan for risks, ensure the status updates they receive are realistic, understand the language the technicians speak and can be the link between technical and non-technical stakeholders.

Project managers need to understand the work being performed. If they don’t, they might be able to act as facilitator, catalyst, motivator, and cheerleader, but they won’t be able to understand or participate in technical problem solving.

Project managers who don’t understand the technology they are managing can lose the confidence of their teams, particularly teams that are proud of their technical ability.

3.???TECHNICAL SKILLS DISTINGUISHES A PROJECT MANAGER

A project manager must have several skills including subject matter expertise. A project manager should be a T-shaped person. A T-shaped person has a defined, recognized specialization and primary role, but has the skills, versatility, and aptitude for collaboration to help other people when and where necessary. This collaboration reduces hand-offs and the constraints of only one person being able to do the job.

The number of technical skills a project manager brings to the table can elevate them from average to expert in a heartbeat. ?

Some of the examples where technical skills are required are;

Communicating with technical people: To communicate effectively with technical people you need to understand their technical concepts. The more you understand, the better. ?In general, the less you understand of the other person's vocabulary, the more likely you are to be “snowed” and the less likely you are to gain the respect of that person.

Technical Credibility: Whatever the nature of the project, the project manager must have sufficient knowledge of the technologies involved to comprehend the problems involved. ??the project manager must be able to demonstrate skills in at least one of the disciplined involved. ?

Understand the tools and methodologies of relevant technologies: Each technology has its own repertoire of tools and methodologies. A project manager need not be able to use each of them, but must be able to understand their nature and underlying principles. This level of understanding helps in understanding what is involved in meeting the project objectives. It will also enhance the image that others on your team have of you and it will further reduce the probability of them being able to “snow” you.

Managing Architectural Spikes: Spikes are useful for learning and may be used in circumstances such as estimation, acceptance criteria definition, and understanding the flow of a user’s action through the product. Spikes are helpful when the team needs to learn some critical technical or functional element.

Reviewing Technical Debt: Technical debt can be caused by many factors like Poor upfront definition, Pressure for value delivery, Lack of documentation, Parallel development etc.

Performing project pre -mortem: Project pre-mortem aims to find failure points before they happen, Imagine the failure, Generate the reason for failure etc.

Help the team with technical project management activities: Sometimes team members may not have knowledge or experience in roles or functions. Servant leaders (as in agile project management) who may have more exposure or training in techniques can support the team by providing training or undertaking these activities.

4.???PRACTICAL EXAMPLE: API IMPLEMENTATION

I will use one of my personal experiences to demonstrate why a project manager should have technical knowledge and understanding.

Almost ten years ago I was tasked to manage the delivery of an internet banking application for a commercial bank. Internet banking, being a delivery channel, must interface with several existing applications to achieve the defined services.

Retail customers registration and subsequent access was to be through debit card number and pin. The internet banking solution vendor had to develop an application programming interface (API) which is able to communicate with the existing card management system (CMS) to achieve the retail customers enrolments and sign on functions.

The API had to also conform to the specifications of an existing hardware security module (HSM) and ISO 8583 transaction specifications. ?Let me give a brief description of API, HSM and ISO 8583.

4.1. API

Application programming interface consist of two main components; Technical specification describing the data exchange options between solutions with the specification done in the form of a request for processing and data delivery protocols and a Software interface written to the specification that represents it.

Most businesses use more than one API to connect applications and share information. Some end up needing an API management tool to help them control, distribute, and analyze different APIs.?

APIs can be grouped by availability, use cases etc.

4.1.1.????TYPES OF APIS BY AVAILABILITY

Private APIs: These are designed for improving solutions and services within an organization. In-house developers or contractors may use these APIs to integrate a company’s IT systems or applications, build new systems or customer-facing apps leveraging existing systems. ?

Partner APIs: Partner APIs are openly promoted but shared with business partners who have signed an agreement with the publisher. ???

Public APIs: These APIs are available for any third-party developers. ?There are two types of public APIs, open (free of charge) and commercial ones.

4.1.2.????TYPES OF APIS BY USE CASES

APIs can be classified according to the systems for which they are designed.

Database APIs: Database APIs enable communication between an application and a database management system e.g. the Drupal 7 Database API, ORDS database API.

Operating systems APIs: This group of APIs defines how applications use the resources and services of operating systems. ?for instance, Windows API or Linux API (kernel user space API and kernel internal API). Apple provides API reference for macOS and iOS, Cocoa set of developer tools and Cocoa Touch. ?

Remote APIs: Remote APIs define standards of interaction for applications running on different machines. ?

Web APIs: This API class is the most common. Web APIs provide machine-readable data and functionality transfer between web-based systems which represent client-server architecture. ??

4.1.3.????API SPECIFICATIONS/PROTOCOLS

The goal of API specifications is to standardize data exchange between services. Standardization means the ability of diverse systems, written in different programming languages and/or running on different OSs, or using different technologies, to seamlessly communicate with each other.

Remote Procedure Call (RPC): Web APIs may adhere to resource exchange principles based on a Remote Procedure Call. This protocol specifies the interaction between client-server based applications. ?

Service Object Access Protocol (SOAP): SOAP is mostly used with enterprise web-based software to ensure high security of transmitted data. ?

Representational State Transfer (REST): The term REST was introduced by computer scientist Roy Fielding in a dissertation in 2000. APIs that comply with REST architectural constraints are called RESTful APIs. ?

gRPC: gRPC is an open-source universal API framework. ?With gRPC, the client application can directly call methods from a server application located on a different computer as if it was a local object. This makes it easier to create distributed services and applications. gRPC is mostly used for communication between microservices because it is available in multiple languages and has a high performance.

GraphQL: GraphQL, initially created by Facebook in 2012 for internal use, is the new REST with organizations like Shopify, Yelp, GitHub, Coursera, etc using it to build APIs. GraphQL is a query language for APIs. It allows the client to detail the exact data it needs and simplifies data aggregation from multiple sources, so the developer can use one API call to request all needed data. ?

4.2. HSM

A hardware security module (HSM) is a dedicated crypto processor that is specifically designed for the protection of the crypto key lifecycle. Hardware security modules act as trust anchors that protect the cryptographic infrastructure of some of the most security-conscious organizations in the world by securely managing, processing, and storing cryptographic keys inside a hardened, tamper-resistant device. Enterprises buy hardware security modules to protect transactions, identities, and applications.

With HSM, You can address compliance requirements with solutions for Blockchain, GDPR, IoT, paper-to-digital initiatives, PCI DSS, digital signatures, DNSSEC, hardware key storage, transactional acceleration, certificate signing, code or document signing, bulk key generation, data encryption, and more.

4.2.1.????TYPES OF HSM

General Purpose HSMs: General Purpose HSMs safeguard the cryptographic keys used to secure transactions, applications, and sensitive data.

Network HSM: Network HSM is a network-attached HSM protecting encryption keys used by applications in on-premises, virtual, and cloud environments. ?

PCIe ?(peripheral component interconnect express) HSM: An embedded HSM, protects cryptographic keys and accelerates sensitive cryptographic operations. ?

USB HSM: HSM that is ideal for storing root cryptographic keys in an offline key storage device. ?

Payment HSM: Payment HSMs are network-attached HSMs designed for retail payment system processing environments for credit, debit, e-purse and chip cards, as well as internet payment applications.

Cloud HSM: With Cloud HSM services, customers can store and manage cryptographic keys, establishing a common root of trust across all applications and services, while retaining complete control of their keys at all times. ?

4.3. ISO 8583

ISO 8583 is an international standard for financial transaction card originated interchange messaging. ISO 8583 defines a message format and a communication flow so that different systems can exchange these transaction requests and responses. In particular, the Mastercard, Visa and Verve networks base their authorization communications on the ISO 8583 standard, as do many other institutions and networks.

The ISO 8583 specification has three parts:

Part 1: Messages, data elements, and code values

Part 2: Application and registration procedures for Institution Identification Codes (IIC)

Part 3: Maintenance procedures for the aforementioned messages, data elements and code values

A card-based transaction typically travels from a transaction-acquiring device, such as a point-of-sale terminal or an automated teller machine (ATM), through a series of networks, to a card issuing system for authorization against the card holder's account. The transaction data contains information derived from the card (e.g., the card number or card holder details), the terminal (e.g., the terminal number, the merchant number), the transaction (e.g., the amount), together with other data which may be generated dynamically or added by intervening systems. Based on this information, the card issuing system will either authorize or decline the transaction and generate a response message which must be delivered back to the terminal within a predefined time period.

4.4. TECHNICAL KNOWLEDGE AND UNDERSTANDING EXAMPLE

Back to the internet banking (IB) implementation, specifically retail customers enrolment and login API using debit card number and PIN. The project had all the necessary structures and resources including Cross functional Team Members like business Representatives, product owners, proxy customers, value management team, technology subject matter experts (SMEs) etc.

For this API we went through the usual steps of defining and documenting the API specifications and process flows. The API specification document was very detailed and outlined all the values. Additionally, the CMS vendor had to provide the debit card Pin verification process particularly the key exchange, PIN block formation method (Pinpad, ANSI).

The chosen programming language was Java on Linux. It was the first implementation where the IB vendor was porting the code to Linux, all their previous implementations were on windows OS.

The high-level data exchange process for this API was a s follows;

a.?????The IB ?application ?initiates a key exchange request to the CMS application.

b.?????The CMS triggers the HSM to generate the keys namely terminal master key (TMK) also called Key encryption Key (KEK), terminal pin key (TPK) and master file key (MFK).

c.?????CMS sends TMK to the IB, uses MFK to encrypt TMK and stores the encrypted TMP in crypto tables and also send a copy to IB.

d.?????CMS stores TPK in the crypto table.

e.?????IB then forms the PIN block using the specified pinpad and ANSI methods (Pin and card number used).

f.??????IB then uses the MFK to decrypt the TMK and uses the clear form TMK to encrypt the pinblock and sends to the CMS.

g.?????CMS uses the defined algorithm (IBM or VISA) to process the pinblock and verify the PIN and send success or failure message to IB.

The CMS vendor developed their side of the API and deployed. The IB vendor also developed their side and deployed ready for testing.

4.4.1.????PIN VERIFICATION FAILED

According to the IB team, this was a very critical development and they assigned their lead (best and most experienced) developer to deliver. They were confident they had implemented all the specifications and algorithms as expected. The CMS vendor position was that the same interface was already working for ATM pin verification and should work in this case provided the pinblock was formed as per the agreed specifications and algorithms.

For a moment there was a deadlock, several joint sessions did not yield much and both vendors were very categorical they had delivered as per the agreed specifications. Time was running out and the steering committee was already thinking of an alternative user enrolment process. Frustrations and pressure was almost reaching breaking point.

Before this role, I was mainly in banking applications management and support and I had developed expertise in problem diagnosis and resolution. I decided to perform a technical review of the API codes from initiation to the pinblock verification. We had already reviewed the logs for the key generation part and compared with the values in the CMS crypto table, all were matching.

I told the IB onsite developer that I would like to walkthrough his code implementation of the pinblock. Pinpad and ANSI algorithms outlines specific steps which must be done right (in IB) for the other application (CMS) to produce the same result. It didn’t take long for us to identify a missing step in the implementation, one of the required paddings was not implemented.

The developer wanted to follow the bureaucratic process of their company which required him to report the discovery to their lead developer who should then review and then decide to modify the code. My position was that route may take long and considering they have always maintained the code is perfect we need to have real proof for them act faster. Since we were in the development environment, we agreed to make a copy of the code, implement the missing step and test the registration. With the change the registration worked, I managed to register with my debit card and pin. We alerted the CMS vendor wo reviewed the logs and confirmed the request was received and processed by the CMS. The IB developer was very elated, it was like he had gotten a new lease of life. “So, this thing can work?”, he asked with a broad smile.

4.4.2.????NEXT TECHNICAL CHALLENGE: NO ONE ELSE COULD REGISTER

Armed with evidence of a successful registration, the IB developer engaged his team and they immediately agreed to make the changes, package the API as a java service and deploy for testing. I also informed the project team members of the breakthrough and everyone was happy and ready to test the registration as soon as it is deployed. ?The steering committee convened a special session to review the next steps.?

After the changes were implemented and deployed in the test environment we were faced with a new challenge, nobody else could register. It was a scenario of reaching climax and anti-climax in quick succession. We were back to technical discovery. During the steering committee session, the chair wondered whether we simply hardcoded my debit card details in the API.

We knew we had a working solution so we dived into research. It was our first time dealing with JBoss webserver and on researching we realized JBoss stores a cache of information that is used frequently in the tmp and work folders. This includes information about configuration settings and also cached pieces of the webpage. The cache can sometimes keep the old information after you have modified it, making it seem like the change didn't complete successfully. We cleared the cache and everything worked fine thereafter, all enrolments tests were successful including negative tests. We added the script to clear the cache in JBoss start-up script.

The IB solution was a great success, it won the best internet banking solution regional award for several years. After this implementation the IB vendor developed an API service with generic common banking services which they added to their service offerings to customers.

Years later as I was charting with the IB developer, I congratulated him for delivering a good solution under a very strenuous condition. “It was all thanks to you, we couldn’t have delivered without you”, he responded.

A project manager must have technical knowledge and understanding.