10/12/03
Kartavya
Abhi
Sanjeev
Pending
Projects
(Dated
10-12-03)
While
briefly discussing priorities of pending projects on Monday, we agreed that “bouncing
back of resumes” deserves higher priority.
Kartavya
agreed to prepare a broad framework / pilot design for this project by weekend.
I
enclose some notes on this project which, I hope, would help Kartavya in this
task.
Depending
upon the progress Kartavya makes on this design by week-end, we will meet on
Monday or Tuesday next week to jointly review other pending projects for which
I have sent you my notes along with a 4-quadrant graphic on 6/12/03.
While
discussing these projects and their priorities, I would like our entire team to
participate in the discussions.
We may need a full day — so please discuss amongst yourselves and let me know
which day.
(Signed)
10/12/03
“BOUNCE-BACK”-ing
of ImageBuilders
(Page
1/8)
Points
Objective:
To get the jobseekers to edit / modify / add missing details in the
ImageBuilder and send it back to Recruitguru for inclusion in the private
database of the concerned subscriber.
How
will this help?
1️⃣ The structured database
will become much more accurate (with hardly any field wrong or missing).
During searches, this improved accuracy will give better search results.
2️⃣ Increased “accuracy level”
will dramatically increase the “confidence level” of subscribers.
(Initially, they would not come to know how much of the accuracy is due to
GuruMine and how much due to validation by jobseeker.)
3️⃣ Getting salary &
designation & tenure of each jobseeker from thousands of jobseekers will
enable us to create database and several new “profiles” as:
- Salary
Profile (Frequency Distribution Graphs)
- Designation
Level
- Tenure
Profile
These
profiles can be for any given Function-Name, and within each function
name, these can be further broken up into sub-populations of a given:
- “Age-band”
- “Experience-level”
- “Education-level”
- “Industry-name”
(when we start extracting)
These
profiles will prove a very valuable “aid” to HR / Recruitment Managers, while:
- Negotiating
salary / designation of a potential / suitable candidate.
- Deciding
annual increment amount of any existing employee.
We
will make all profiles & all sub-profiles paper-use transactions (options).
4️⃣ A “bounce-back” partially
fulfills the role of “Feedback from Employer to Candidate.”
At
the very least, a bounce-backed ImageBuilder is an acknowledgment that the advertiser
(company) has, in fact, received that resume and taken note of it.
Now,
when the ImageBuilder (bounce-back) is accompanied with a “covering letter”
(email), promising to add that resume to the company’s LIVE database if
the candidate will only take the trouble to edit / update & return —
Then,
the candidate’s hope gets multiplied manifold!
There
is an implied threat / fear that if he does not take this trouble, he stands to
lose out!
“It’s your funeral” kind of message!
As
Jeff Taylor (Monster) said, candidates around the world have one main
grudge against employers, viz.:
- “They
never get any feedback! Apply, apply, no reply!”
So
I feel, bounce-back will go a long way to fulfill this long-standing
& universal “felt need” of jobseekers.
In
the process, it will also build up the reputation of the (subscribing)
organization amongst jobseekers, as a
Responsible
/ Responsive Corporate Citizen —
something
which millions of dollars’ worth of ads cannot do!
Because
of the fact that they can expect to receive a feedback (in the
form of bounce-back of ImageBuilder) from a certain subscribing company, there
will be a pronounced tendency amongst jobseekers to apply against that
particular company’s job-advt.
So
a subscribing company can look forward to receive a much better response
to its future job-adverts — both quantitatively and qualitatively.
For
a subscriber company, this in itself is a very advantageous position — vis-à-vis
those companies who are not subscribing to Recruitguru.
6️⃣ Once they have received an
ImageBuilder (from the first bounce-back), it is quite possible that some
jobseekers will simply keep on updating the ImageBuilder every time:
- they
change their job
- they
get promoted
- they
get salary rise, etc., etc.
AND
send it back to Recruitguru, on their own, again & again — whether there is
a job-advert from that company or not!
They
will assume (and rightly) that every ImageBuilder coming in directly from
candidate himself will get uploaded in the private database of the subscriber
to whom he had originally sent his email resume!
And
if this assumption is right, it will prompt the candidates to keep updating
their ImageBuilders again & again — whether asked for or not.
After
a while, it may even so happen that some candidates, who have managed to get
hold of an “ImageBuilder” (other than through a bounce-back), may also adopt
this technique!
Obviously,
when Recruitguru sends out the ImageBuilder to a candidate for the first time
(with the covering letter), somewhere that ImageBuilder must carry two
numbers, viz.:
- Subscriber
(i.e., Customer) Number:
- The
one who sent that resume in the first place for processing, and therefore
belongs to him (to be deposited back into his private database when
returned after editing).
- PEN
To identify, we need both. Then only we will know in which private database to deposit, when received.
Of
course, it may happen (— will happen) that a given candidate has sent his email
resume to six subscribers, and Recruitguru receives all these six
identical resumes for processing.
Our
Gurumine software will deposit these resumes (all text identical) into
six different private databases — but all carrying the same PEN.
And
then, the bounce-back feature will send out six ImageBuilders (all identical)
to the same candidate, with identical requests to edit / modify &
return.
But
each covering letter will mention the name of different advertiser company
— even though PEN is the same.
So,
it’s the unique combination of
- Permanent
Customer No. (PCN)
- Permanent
Executive No. (PEN)
which
will decide which edited resume goes into which private database.
This
is why, in our covering letter, our subscriber / customer / advertiser’s name
must be written in bold capital letters, so that jobseekers know that he
has to edit & return ImageBuilder to all of these companies
individually.
Whereas
a given candidate’s resume may belong to 6 subscribers’ private databases (with
same PEN), it would be desirable that within one specific private database,
there should be no more than one resume of any given candidate at any
given point of time — (the concept behind “duplicates”).
However,
this must always be the latest (last-arrived) resume, if it is
established as duplicate.
The latest must overwrite the previous one. (We are doing the same thing
in Module 1 — but maybe manually. In Gurumine, this must happen automatically.)
Whereas
this principle is understandable, what happens to the:
- Function
Profile Graphs
- Salary
- Designation
Level
- Tenure
etc., etc.
where
we have treated the old/obsolete ImageBuilder as one incidence / record /
occurrence and extracted / used a lot of data in order to plot these
graphs?
Every
time a latest (duplicate) resume overwrites previous resume — what do we
do?
The
graphs will anyway stand “altered” as soon as our software inserts fresh
data contained in the latest resume.
But
the question is —
“Since
the graph is anyway going to change because of latest data, do we
simultaneously delete the old data taken from previous resume?”
My
answer is NO.
One
simple reason is to simplify the working of the software.
As
it is, the arrival of resumes (picked-up data, from which to generate various
profiles) will grow rapidly. Therefore, I would accept a scenario where various
profile graphs get updated only once-a-day and not in real time.
But
if there are too many “duplicate” resumes, deleting old data will increase the
complexity of the software.
In any case, as far as graphs are concerned, we are merely concerned about the sample-size
(the population & sub-populations) — and not with a particular PEN.
10-12-03
Kartavya
Abhi
Sanjeev
Gurumine
Display
|
Batch
No. |
|
|
Status |
|
|
Pending |
|
|
Processed |
|
|
Extracted |
|
|
Rejected |
|
|
Duplicates |
|
|
Start
(Time) |
|
|
Last
Processed |
|
|
Process
Time |
|
|
Time
/ Resume |
|
|
Start
PEN |
|
|
End
PEN |
From
subscriber’s point of view, Batch No. is irrelevant.
I
suggest we modify this display as follows:
- Cumulative
Uploaded
- Cumulative
Processed
- Cumulative
Extracted
- Cumulative
Time Taken (hrs)
- Average
Time / Resume (sec)
→
Extraction Statistics
Clicking
on this will display the following tabulation:
|
No.
of Fields Extracted |
No.
of Resumes (Frequency) |
|
1 |
|
|
2 |
|
|
3 |
|
|
… |
|
|
23 |
|
|
Cumulative
Total |
Perhaps
we can make these links clickable.
I
want to drive home the concept that there is no such thing as “rejected” —
there is no black or white.
Even “duplicates” are processed!
By
clicking on this link, one can see frequency-distribution graphs updated every
10/12/03
Kartavya
Abhi
Sanjeev
Processing
Speed
- See
enclosed graph.
- This
(improvement of extraction-speed) is obviously our highest priority.
If some 10 companies were to subscribe in the next 10 days and start extracting their resumes, then what is merely “very important” will become a “CRISIS”! - In
fact, every subscriber must be able to see such a graph for his own
private database — anytime he chooses!
(arrow
at the end of page)
06/12/03
Kartavya
Sanjeev
Abhi
Subject: Prioritizing
of Balance Projects
- Enclosed
find summary-graph of discussions we had last week.
- We
must take a fresh look at these Monday morning.
- Idea
behind taking a fresh look is to leave Kartavya free during next 4
weeks to focus/concentrate on planning & design, so that even
after he leaves, software developers can continue their development work
based on these plans/designs developed & documented.
- This
implies that Kartavya should not involve himself in day-to-day routine
supervision/guidance of Regi, Vrikram, etc.
- Since
Sunitha too has resigned (but will be available for 1 month), we
could/should consider her to assist Kartavya in converting these plans/designs
— and not be given any routine software development work.
- In
my opinion, Gurumine and Interview Mgmt Modules deserve
highest priority.
(Signed)
Kartavya
20-11-03
Software
Development Projects
MASTER
PLAN – Setting of Priorities
I
refer to my yesterday’s note in which I had developed a matrix of 9 blocks,
along
→ X-axis = Importance (High / Medium / Low)
→
Y-axis = Urgency ( )
Only
7 blocks had some entries; 2 had none.
Out
of these, I again knocked out 2 blocks, viz.:
- Low
Importance & Low Urgency
- Low
Importance & Medium Urgency
In
the enclosed ANNEX, I have listed the projects falling under the balance
5 blocks.
Within
each block, I have listed projects in order of their relational / overall
priorities, as perceived by me.
Obviously, these priorities are subject to debate & re-management.
Of
course, if we can quickly develop those “computerised worksheets” for
“priority ranking,” nothing like that — where data would be more objective as
compared to ANNEX.
But,
if that is going to take time, in the meantime we could develop a
TENTATIVE
PROJECT PLAN
based
on my ANNEX.
Then,
as & when objective ranking/rating gets ready, we can always re-cast the
plan.
In any case, by their very nature, project plans are dynamic and need revision
from time to time.
But,
we need “a plan” soon, no matter how crude or subjective!
We
must know:
- Who
is going to work → (Resource)
- On
What → (Project)
- When
→ (Start)
- For
How Long → (End)
We
need a Compass and we need Benchmarks, so that we can align our
energies to achievement of Targets.
Such
a priority list will help me go through my past notes (on each topic) and
synthesize into sharp Functional Specifications / User Interfaces.
How
soon?
(Signed)
SOFTWARE
PROJECTS (Development Priorities)
Dated:
20-11-03
(1)
Category – High Importance + High Urgency
- Bounce-back
of ImageBuilders
- Subscribers’
Flight-Deck (balance work)
- Guest
Trial
- Profile
Graphs for IT Professionals
- Extraction
of USA-style Resumes
- Job-Mining
(Robot Auto-Converter)
- Extraction
of “Industry” field
- Search
by “Vacancy-Name”
- GuruAd
(2)
Category – High Importance + Medium Urgency
- Auto
Pattern Scanning & Intelligent Spider
- Recruitguru
Flight-Deck
- ImageBuilders
received from Placement Agencies
- Extract
Resumes of Fresh Graduates
(3)
Category – Medium Importance + Medium Urgency
- Subscribers’
List
- Percent-bar
Comparison
- Integration
with OES
- Integration
with SAP / BAAN, etc.
(4)
Category – High Importance + Low Urgency
- Various
Links
- Competitors
(Winner–Prize)
(5)
Category – Medium Importance + Low Urgency
- Speed
/ Accuracy Graphs
- Profile
Calculator
- Deeper
Extraction / Data Mining
- Pattern
Recognition
- Pay
Analysis
- Creating
Subscribers’ Employee Database
- Tool
for Improving Extraction Accuracy
- Aggregation
of Searches
Software
Projects Master Plan
Kartavya
19-11-03
While
you, Abhi, and Sanjeev are working on worksheets to assign a raw score /
weightage / priorities to different projects based on several criteria —
enclosed find my rating / ranking of these projects based on just two
criteria, viz.:
- Importance
of the project
- Urgency
These
ratings/classifications are obviously based on my intuitive feeling /
perception of what our clients/subscribers might want and how
badly they might want it.
Ideally,
we should be talking to a group of HR / Recruitment Managers and ask them
what they find important and urgent.
But
I have a serious doubt whether they know what they want — much less, why they
want it!
I
have a feeling that if we were to ask 10 HR Managers, we would get thoroughly
confused by their contradictory requirements.
It
reminds me of the ancient parable of “Seven Blind Men & the Elephant.”
As marketers, we will tell them what they need & will use.
(Signed)
Further
Projects
Kartavya
14-11-03
You
will recall that around Nov. 1, we discussed (though very briefly) a Master
Plan of Projects, which broadly covered:
→
New Modules of Recruitguru (RGN)
- GuruAd
- Interview
Mgmt. Module
- Employee
Mgmt.
- Organization
Module
→
Existing Modules of Recruitguru (RGE)
- GuruMine
(Major New Features / Minor Improvements)
- GuruSearch
→
Common Features (RGC)
I
had proposed a “Scoring / Ranking Matrix” for individual projects in
order to arrive at their relative importance to our business, and hence, their
priorities.
Out
of the above-mentioned projects, I have taken the Common Features (some
10 items) and tried to fill in this matrix.
I
enclose this matrix, along with 3 pages (CF1 / CF2 / CF3), which give
brief descriptions of these projects.
Whereas
the score / weightage given by me to each project (on each parameter) is
certainly subject to debate & modification (which we must do jointly with
Abhi & Sanjeev), what is important at this stage is to finalize or freeze
the worksheet design (scoring formats / parameters) before we spend a lot of
time in debating / filling up these forms for 50–60 projects.
I
would appreciate if you could take a close look at this note and come up with a
better worksheet design over the weekend.
Then
next week, we can carry out the scoring / ranking (using your improved
worksheet) jointly or individually — and then take the averages.
It
is not enough to figure out the priorities within a particular category
and across all categories.
Once this is ready, we can figure out the time-frame and resources.
(Signed)
14-11-03
No comments:
Post a Comment