As I've mentioned before, project management by itself is no longer in strong demand these days. Companies are looking beyond generic project management skill sets to specific expertise.
For example, a bank may want a project manager who understands corporate actions processing, the trade life cycle or client on boarding processes. A petroleum company may look out for project managers who understand the petrochemical industry.
Take myself as an example. In the late 1990s, when I was a fresh graduate from the National University of Singapore, there was a huge demand for IT talent in the country.
With the Internet boom at its peak, companies like IBM, Accenture and HP were looking for the best IT resources.
Although I was trained in Electrical Engineering, I made the switch to IT and worked for an American company delivering complex system implementation projects.
Most of my colleagues liked to be in projects dealing with the sexy topics of that time, i.e. J2EE and "e-business".
They liked to talk about how client server architectures were transformed into three tier architectures. How Enterprise Data Management (EDM) - the precursor to SOA and web services - could be used to orchestrate application messaging in companies' technology backbone.
For me, I knew about all this technical stuff - in fact I tried to pick up what I could about J2EE and related technologies.
However, I found that I was more interested in the "business", i.e. how a bank runs it's client account opening process, or how a retail store performs cashiering.
So instead of signing up for technical roles, I decided to go for "business analyst" roles. That gave me a lot of exposure to business users and I was able to learn the ins and outs of a bank, for example, after participating as a BA in a core banking system implementation.
I took up BA roles for a lot of projects - from the years 2000 to 2007, I ended up getting business exposure in a wide range of industries, from the public sector to banking, insurance and the capital markets. I also started doing junior PM work in addition to my BA role, and also running testing streams for some of the projects I was in.
Fast forward to 2007. It was then that I begun to realize that I had domain knowledge, but across a huge number of industries. That effectively did not work out too well.
If there was a core banking system deal that the company was after, I'd not be the subject matter expert who would be consulted. If there was a CRM project in a telco company, I would also not be the subject matter expert. A subject matter expert would need to know the industry and vendor software solutions pretty much inside out.
Hence, for myself, I felt handicapped because I was not strong in any ONE industry. I resolved to correct that.
Industry knowledge is tremendously helpful in project management
So I started to think, which industry has the most projects and most demand for business analysts and project managers? The answer was simple - financial services, and in particular, banking.
So I left my company to join a bank as the next step in my career. I then started to develop in-depth industry specific skills in banking and today, I can say I have banking domain knowledge AND project management capabilities. That is a potent combination that really shines on a resume.
Now I do realize I'm getting a little off track from the intention of this article - which is to tell you about how industry knowledge helps in project management.
I can think of at least four reasons why it helps - so here goes:
As a project manager, you're often updating and working with very senior executives in a company. If that company is a bank, for example, the senior executives expect you - the project manager - to speak their lingo.
Imagine what might happen if you go into a boardroom and some executive (yawning and trying to pay attention) drops a bomb and asks you "What about bond coupon payments? Is the system able to handle clean and dirty bond prices?", or "Does the system cater to FX accumulators - do I need to do it in your system or another external trading system?"
Without domain knowledge, you're NOT going to be able to answer questions like that.
Case Study. In fact, the questions above WERE indeed raised to me in a Project Steering Committee meeting at a banking client of mine. I managed to answer them with aplomb because I had prior exposure to these topics.
For you info, clean bond prices means that e.g. the bond is valued ON say, a coupon payment date. A dirty bond price is one where you need to accrue additional bond interest from the LAST coupon payment date until the valuation date).
FX accumulators are usually maintained in a trading system like Murex and consist of underlying FX options. You usually must have dedicated systems to track their trade lifecyle - setting up the product, booking the accumulator, "fixing" the accumulator (i.e. to decide if each underlying FX option is exercised and therefore results in a FX spot being performed for the client.
Now, imagine being able to answer THAT to a user. Don't you think the user will be duly impressed?
How did I gain enough domain knowledge to know what clean and dirty bond prices are? Or how FX accumulators work? Well, I think for myself, I've had the benefit of working in banks and also studying a quantitative finance degree.
Over time, you start to see some of the key trends and operational issues users face. And here's a little tip - I keep a journal of the industry knowledge and terms I learn on the job. This log has helped me tremendously in picking up (and retaining) knowledge over the years.
So the lesson here is - pick up industry knowledge, because your users will begin to see you as credible.
Knowing their lingo helps you "get through" to users more quickly and just makes things like requirements gathering, sign-offs and managing user expectations that much easier.
This may sound obvious, but having industry knowledge helps you gather better requirements if you're implementing a system.
Let me give you an example. Let's say you're trying to implement a trading system for a bank, specifically to process equity trades. If you had industry knowledge, you'd know that processing an equity trade, in the banking industry, requires the following steps:
Capture equity order - the user keys the desired stock counter and price into the system. The system goes to the market (usually the stock exchange of the counter) and checks if there is a matching trade at that price.
If so, it updates the trade as "Executed". This also depends on the type of equity order being placed by the user, e.g. Market, Fill-or-Kill, Good-Till-Canceled.
Confirm equity order - the back-room operations would usually take the dealer's trade ticket (a piece of paper or an Excel log) and match it against what has been keyed into the trading system. The trade will probably be updated to a status "Confirmed".
Settle equity order - in Asian markets like Singapore, equities are settled T+3. This means that you'll have to pay up for the stock you bought in three days - if I bought ABC stock on 14 Jan, I'd need to pay up by 17 Jan.
The system would automatically debit the client's investment cash account and credit the relevant shares into his or her account.
Now, if you had the benefit of industry knowledge, do you think the above requirements would be easy to write up?
Of course! It took me all of eight minutes to write up the above. If I didn't know how equities were processed and their associated trade life cycle, I'd have to take days to understand and write those requirements.
If you're a project manager now, gaining industry knowledge helps you move on to alternate careers later.
Wondering what I mean?
Well, project managers run projects. I'd gather system requirements, manage a development team, run testing streams (SIT and UAT) and deploy the system.
If I do such projects for a specific industry (e.g. private banking), I might start picking up industry knowledge along the way. If I run three to five projects for private banks, I may then know the ins and outs of what private banking is about.
Suppose I get tired of being a project manager and want to move on to the role of "Private Banking Relationship Manager" (i.e. private banking sales), or if I wanted the role of "Operations Head - Corporate Actions" in a private bank, do you think I can get the job?
Well, I certainly think I have a good chance!
You see, the good thing about the project management + industry knowledge combination is the broad coverage and potential applicability to many areas. In the above example, I can go on to run projects in a private bank.
Industry knowledge can help you secure jobs
I can become an RM, operations guy, compliance guy, or IT guy. If I go even further to deepen my industry knowledge (e.g. do a part-time degree specializing in private banking) - I'd greatly increase my chances of snagging such jobs.
So the net of it is, with industry knowledge, you can open up a diverse range of career options after your role as a project manager.
Part of our work as project managers is to estimate work effort. If I ran a project, I would need to know how much time is needed for business process re-engineering, gathering requirements, development, testing and deployment.
Now, if I know intimately the nature of each task in my project, do you think I can estimate details more accurately? Of course I can!
Take an example. Let's say I have a task "Create test scripts for fixed income module".
If I didn't know better, I might put a block of 10 man-days for that effort.
But if I KNEW fixed income consists of setting up the product, trade capture and processing, as well as corporate actions - I might then bump up my estimate to 15 man-days, knowing there is a lot of ground to cover.
In essence, having industry knowledge helps you, as a project manager, understand the nature of tasks better in your project.
This helps you capture better work estimates. And with better estimates, you increase the chances of successful project delivery.
The final point I've to make about industry knowledge is the project management community.
If you have industry knowledge in a hot topic, e.g. private banking or insurance here in Asia, there is a very good chance the project management community wants to hear from you.
Case Study. Here in Singapore, the Singapore Management University runs a graduate-degree course on information systems with a focus on banking.
It is immensely popular with those working in IT within banks and I've in fact considered teaching the course too, given my background. There are also other project management bodies in Singapore which are interested in hearing about "industry knowledge" from practitioners.
So my point is - if you have an interest in teaching or sharing your knowledge - you should know that industry knowledge is something that many, many project managers want to beef up. If you have that knowledge, great opportunities are abound for you to share it.
I hope I've helped you understand how industry knowledge can help in project management. It helps you build credibility amongst your users. It helps you gather better requirements and estimate work effort more accurately.
It's also tremendously in demand in the project management fraternity.
If you want to beef up industry knowledge, my recommendation three-fold.
The first is to look for a part-time academic credential. There may be some courses at the local university or polytechnic for boosting your knowledge.
The second thing you should do is to get into industry specific projects. This will be simpler if you're already in a company (of the industry you want to be in) working as a project manager.
For example, many project managers I know have worked in one bank for over 20 years and they have A LOT of industry / domain knowledge.
The third thing you can do is to get a mentor. Many people overlook the mentor aspect. I know someone who has spent 20 years in banking and has delivered at least 8 core banking projects.
If you're in the banking industry, you'll know that is A LOT of experience.
Having someone like that teach you about the industry in an informal manner, or coaching you in getting the correct projects or job positions, will help you to no end in your career.
Try it out - find someone you can identify with and ask to be mentored by them.I've also written about various ways to increase your domain knowledge in a project over here.
That's all for now, folks. Until next time, have fun building up industry knowledge and managing your projects!
Are you wondering how to break into a Project Management?
Would you like to understand how others have successfully switched to a PM career?
Or discover what skills, certifications and domain / industry knowledge are required to excel in a PM role?
I’ve written a practical, easy-to-read guidebook that will help you find your best path to Project Management – one that leverages your unique skills, experiences and career background to your advantage.