Hi,
I'm about to be assigned the task of taking over a small company that
provides services in the mobile phones/handheld content and marketing
area.
My role would be to get a handover of all systems and documentation
along with staff screening and organization re-structuring along with
all financial and business related documents and processes. Where
there is a lack, it will be my job to create those lacking portions
and ultimately keep the people we find of value and then make sure we
re-develop a business plan along with all the financial and marketing
portions.
The core of the work will be to aquire their intellectual property
which will be in the form of applications, code in different languages
and probably very little documentation to speak of.
My deliverables will need to include the above with documentation
which would allow the new owners to feel comfortable that they've got
a grip on things. The new owners can make sense of the documentation
so it won't go to waste. :-)
I need advice and guidance in how to go about this from someone who's
willing to go into a bit of details and carry a discussion here. I'm
not particularly interested in many references to good materials to
read on the subject, so it would be your role to give me what anyone
in my situation with intermediate experience in managing companies to
take over this new investment with specific processes and types of
documents and tasks that they found to be of value in such a situation
and what to look out for as well as the typical priorities of such a
practice along with the risks involved.
Thank you.
/Lizardnation |
Request for Question Clarification by
aht-ga
on
08 Feb 2004 13:49 PST
lizardnation-ga:
It sounds like what you are looking for is similar to the type of
advice that one typically turns to a mentor for. This mentor can be
either inside your company, or an objective, experienced individual
outside your firm. We'll have to see if Google Answers can be a
sufficient forum for the latter, since GA does not facilitate private,
near-real-time conversation. As well, GA Researchers are not permitted
to engage in direct contact with clients outside of the GA
environment. The lack of both of these capabilities may prove too much
of a hindrance to allow for proper, open discussions as you proceed
through your assignment.
Can you clarify whether you have any of the following resources available to you?:
1) A person or persons who can provide feedback on the evolving
expectations of the new owners (ie. a supervisor, manager, or even the
owners themselves);
2) Access to corporate standards for documentation of software code
and of company practices;
3) Access to change management experts (in your firm's HR dept, for
example) to help in integrating the employees of the acquired firm
into your firm;
4) Access to an accountant (in your firm, or retained by your firm) to
audit the finances of the acquired firm prior to integration;
5) Access to developing a good relationship with a team lead from the
small business (who will hopefully be retained after the
integration!), who can help be your representative to the rest of the
brain-trust in the small firm and facilitate getting the documentation
created.
Also, can you describe whether the takeover is an amicable one? How do
the employees of both the small business, and those of your own
company, feel about the takeover?
I'm not sure if there is much help that I or my fellow Researchers can
provide within the mandate of the Google Answers system, but your
response to the above clarification points will help in determining
this.
Looking forward to your reply,
aht-ga
Google Answers Researcher
|
Clarification of Question by
lizardnation-ga
on
08 Feb 2004 14:53 PST
Hello AHT,
Thanks for the help, my responses are below:
1. Have access to all owners and all involved staff.
2. Owners have no previous experience or policies in technology
investments and as such have no or very few applicable documents and
policies. I'll need to come up with those.
3. The acquired company will not be merged. Should be kept seperated
and independent where that can be done efficiently. The number of
acquired staff doesn't exceed six people.
4. Yes, have contracted a firm to take care of accounting and audit
needs of all companies the investors acquire and they only need
guidance, but lots of it due to the area not being familiar to them.
5. I'll be taking care of that for now and hoping to keep them all. :-)
The takeover is not friendly due to the hinted holding of source code
by the development team away from the owners if they're mistreated.
They have sold the company at a reduced cost to our investors to
properly take over the team, their work and the company's assets. The
team is young in age and their reaction is somewhat typical, we think
there's a way to come to an appropriate situation without a
confrontation. That process would be a total audit and documentation
project as well as a business process/workflow mapping and job
description overhaul which would extract the required assets we need
to be in a controling situation of the company that was acquired.
/Lizardnation
|
Request for Question Clarification by
aht-ga
on
08 Feb 2004 15:41 PST
So if I interpret the situation properly, there is a good chance that
the six-person team may want to intentionally hold back on proper
documentation, in order to maintain leverage over the new owners.
It sounds like the immediate need isn't so much documenting and
restructuring the company, as it is winning over the enthusiasm of the
staff. If I were to put myself in their shoes, the only apparent
purpose of anyone asking for documentation would be as a precursor to
letting the staff go and farming further development out to cheaper
developers. Any other reason would pale in comparison to that, since
my job security is the only important thing to me at this point. So,
the first step would be to find a way to make each and every single
member of the developer team feel that the most important thing they
can contribute to the team is their share of the documentation.
Are there any new projects that you would like the team to start
working on, that they could be excited by? Is there any way to make it
so that the new project depends on proper code documentation?
Do you have the flexibility of hiring a couple of new, junior
developers, who can slog through the code as part of their training,
giving them the opportunity to pick the brains of the current team in
order to attain the proper level of understanding?
Since it sounds like the new owners are not necessarily going to take
a part in the day-to-day operations of the business, you may also want
to consider making the 'natural' leader of the team more directly
accountable for producing the documentation. Is there any way to make
this a stated objective that ties into this person's compensation, in
the form of a bonus?
Can you also clarify for me the situation leading into the takeover,
and what the previous ownership structure of the small business was
like? Was any part of the company owned by the developers? If so, are
they feeling that they haven't received full value for their share?
Thanks,
aht-ga
Google Answers Researcher
|
Clarification of Question by
lizardnation-ga
on
08 Feb 2004 16:39 PST
Hello AHT,
The team owns a minority small share of the company and currently
there's no performance structure that ties into their income. This
will be the first thing I'll change where everyone will have
objectives, some fiscal and others will be related to internal goals,
customer satisfaction survey's and growth achievements and so on. I
have no idea what the team thinks, I haven't been given the green
light to approach them, but I will when I present a game plan that is
approved and I proceed with the project.
Sacking the whole team if found to be necessary and replacing their
work through an off-shore team will not be comfortable, but can be the
last straw. which will build and handover the replacement in around
60 working days to the team we bring in gradually and that can take
place as soon as I understand their services and meet their customers
and get a good feel for what is provided and work my way backwards if
things go south.
I'm going to take their threats seriously once they exceed deadlines
on the efforts to get them inline with proper business requirements.
I'll probably go with focusing on the new business plan and ideas and
inject the acquiring of the code and getting it documented in there
somewhere. I would like to discuss how to make the process
comfortable enough not to trigger alarms. I would also like to examin
how to go about getting code submitted, mapped, tested to verify it
does what is expressed that it does. I would understand if you're not
familiar with this area.
Let me know if I missed anything. :-)
/Lizardnation
|
Request for Question Clarification by
aht-ga
on
08 Feb 2004 17:09 PST
Perhaps the best message to relay to the team, when you do first sit
down with them and introduce yourself and your goals, is to let them
know that they are the first and preferred team to continue the
operations of the business. They need to realize, though, that the
continued operation of the business depends on their active and loyal
participation.
Since it is a team of six, and therefore likely to be very loyal to
each other, I would still suggest identifying the natural leader, and
speaking to him/her individually first, to verify to yourself that
they are on-board with your goals and understands why you will be
asking the team to do the things that you will be targeting in your
plan. That will help in integrating yourself into the team, as it
should cause the other five members to respect your leadership if
their natural leader demonstrates that he/she respects it. With their
respect, your task is no longer to try to 'make them' do anything, it
becomes a task of helping them work better. Yes, I know this sounds
very touchy-feely, but that's what the bulk of change management is
all about.
The best way to know what will set off alarms, is to have an open,
honest discussion with the team as part of your initial meeting with
them. This should take place immediately after you meet with the
'natural' leader, preferably the same day to minimize the amount of
talk that will happen in the team in between. The goal of the team
meeting will be for you to outline your plan (to show that you have
one, extremely important), to involve them in developing the plan (so
that they can start to see it as their plan, too), and to provide the
team with the opportunity to air their concerns. Provide as much time
as the team needs for this, but be careful not to allow the
conversation to become a "you versus them" type of discussion. That
may be the natural tendency since you are the outsider, but conscious
attempts by you to use terms like 'we', 'us', 'together' will actually
help to subconsciously influence the mindset of the team.
Be sure to let the team know that the reason the new owners purchased
the company is because of the amount of respect the owners have for
their work. Appeal to their pride, as this will be the first step in
convincing them to document their past and future work. Try to gain a
deep understanding of the role each team member plays, before you
begin to ask for deliverables from any individual. You may even want
to have interviews with each member of the team to let them each
describe to you what they do; a reverse job interview. Keep it
informal, and one-on-one, so that they also have the opportunity to
get to know you. This will reduce the level of threat that they may
currently feel, with the change in ownership and uncertainty about
what your plans are.
Finally, express an active interest in how the team produces the work
that they do. This is actually tied into your most recent question
above, about how to verify the software development process. After you
have had the individual reverse job interviews, ask the person or
persons involved in compiling and releasing the software to show you
how it's done, starting from how the code is developed, all the way
through to commercial release. In doing so, you are giving them the
chance to 'show off' their systems and tools/toys, and you are also
going to gain an appreciation for the processes and methods that are
in use, even if they are not documented. This will also give you the
excuse you need to be around to see the 'final' version of the code
being compiled into the 'final' release, perhaps the best way to
verify that the code actually does what it is supposed to do. Beyond
that, the only other way to obtain an independent assessment that the
documentation and mapping is correct would be to commission a software
audit by a software consulting company, that can be extremely
expensive depending on the complexity of the code.
You will undoubtedly have a lot of questions over the next few weeks,
questions truly best fielded by a mentor in your area. Is there anyone
that you can turn to, either within your own company or in your
network of contacts, who can provide you with their insight into your
continually evolving situation? While I am happy to help where I can,
the GA system is not appropriate for your needs, especially once you
meet with the team and your questions become a lot more dynamic and
urgent.
Regards,
aht-ga
Google Answers Researcher
|
Clarification of Question by
lizardnation-ga
on
09 Feb 2004 03:23 PST
Hello AHT,
Thank you for everything, I will have a few questions till Monday
where I will need to submit a brief of how I will approach the project
to the investors. Your comments were eye openers indeed! :-)
I do use eLance a lot as Humblestart, so I'll be looking to cover the
skills and knowledge needed through people I locate there.
/Lizardnation
|
Clarification of Question by
lizardnation-ga
on
11 Feb 2004 01:06 PST
Hi,
What do you know about CM Audits? I'm assuming they'll help in the
audit plan I would like to draw up for the company's IT area.
Thank you.
/Lizardnation
|
Clarification of Question by
lizardnation-ga
on
11 Feb 2004 01:08 PST
By the way,
I would appreciate it a lot if you progress responses to questions
that I send to you today as soon as you can if you'll be able to. I
need to send a highlevel draft today on what I will later be sending a
compiled version of. :-)
Thank you.
/Lizardnation
|
Request for Question Clarification by
aht-ga
on
11 Feb 2004 08:57 PST
Good morning, lizardnation-ga!
I never did ask what time zone you are located in; I'm in the Pacific
Time Zone, myself (-8 from GMT). I mention this, because your most
recent clarifications were posted at the equivalent of 01:00am my
time!
The term "CM Audit" is not one that I am instantly familiar with, so
that might tell you something right there. As far as audits go, I am
much too familiar with them, unfortunately, having had to be involved
with everything from process quality assurance audits, to financial
audits, to inventory management system audits (glorified name for
convincing a team of 'auditors' to count every single nut, bolt,
screw, and electronic component in a warehouse. Fun... NOT). When you
say "CM", I think of everything from change management to capability
maturity (as in, the SEI-CMM approach for software quality assurance),
but what you mean by "CM" exactly, I am not sure.
So, given the urgency and timing of your clarification, I am not sure
that I can help you with this! Can you clarify what 'CM' means to you?
Thanks,
aht-ga
Google Answers Researcher
|
Request for Question Clarification by
aht-ga
on
11 Feb 2004 09:03 PST
One more thing I should mention (related to the urgency/dynamic
questions point from my earlier postings): the time delay between when
you post a Clarification, and when I get informed that you have
replied to a Request for Clarification, tends to range from a few
minutes, to sometimes over two hours, depending on how busy the GA
server is. Once sent, I get informed of the e-mail immediately at my
end, but the time delay before the message is sent can also be an
issue in providing an immediate response.
aht-ga
Google Answers Researcher
|
Request for Question Clarification by
aht-ga
on
11 Feb 2004 09:08 PST
And one final thought to pass along; given the length of this thread,
I suspect many of my fellow Researchers may already assume that you
are being served, and may no longer be reviewing this question.
Perhaps you can get faster, more timely responses if you expire this
question, and post any new questions that come up as a new post, with
a link back to this question so that the Researcher who responds is
fully aware of the context. The URL for this question is:
http://answers.google.com/answers/threadview?id=304683
Just an option to consider, as my primary concern is that you receive
the timely and accurate Answers you need to succeed!
Regards,
aht-ga
Google Answers Researcher
|
Clarification of Question by
lizardnation-ga
on
14 Feb 2004 01:24 PST
Hello AHT,
Thank you for your concern over my interest, I feel confident that I'm
in good hands and won't expire this question till you paste a summary
of your response in the answers field and finish up a few things here
and then so I can rate the question and I will then open an new
question for any issues that spring out of this one that were majorly
not covered in my original question.
Oh yes, my time zone is GMT+3, but don't worry about my availability,
it isn't due to the time zone difference, though is due to the fact
that I'm in and out of meetings more frequently now than before as a
result of what we're discussing. :-)
/Lizardnation
Thank you again.
|
Request for Question Clarification by
aht-ga
on
14 Feb 2004 10:36 PST
lizardnation-ga:
I will continue to provide whatever help I am capable of as you go
through this project.
I presume that you have now submitted the high-level plan overview. I
will continue to respond to your queries using the request for
question clarification function, until such time as we are mutually
sure that I can indeed summarize my input into an acceptable Answer.
We have just over three weeks to go before your question will expire
automatically, and these next three weeks will be extremely fast paced
for you!
Regards,
aht-ga
Google Answers Researcher
|
Clarification of Question by
lizardnation-ga
on
14 Feb 2004 13:11 PST
Hello AHT,
Yes I have sent in my high level document and I'm exchanging emails in
remation to clarifying and discussing what's in it till it's fine
tuned.
As to my question about audits, I'm interested in audit methods that
are designed for auditing software development department without
being too difficult to apply and maintain and assures the company
retains its intellectual property.
Thank you.
/Lizardnation
|
Request for Question Clarification by
aht-ga
on
14 Feb 2004 16:20 PST
For the scenario that we are discussing, namely a team of about six
developers, the best framework that we can look at is the Carnegie
Mellon Software Engineering Institute - Capability Maturity Model,
Team Software Process (SEI-CMM TSP(tm)). It's a very long name for
what many 'mature' software developers would call 'common sense'. From
my own experience of helping an organization design and implement a
set of software development practices to help achieve higher SEI CMM
Levels of performance, I know that for many software developers, it is
anything but 'common sense' even if it is such an important part of
being a 'professional'.
Here is the overview page from Carnegie Mellon's Software Engineering
Institute regarding TSP and the individual version, the Personal
Software Process (PSP).
http://www.sei.cmu.edu/tsp/
Like any managed change in process, the success of creating this
cultural change depends completely on the willingness of the
developers to embrace the necessary processes that form a Software
Process.
I will put together some references to good starting points, and any
useful case studies that I may find, to help you decide if this is
something you want to ask your team to do.
Regards,
aht-ga
Google Answers Researcher
http://www.sei.cmu.edu/tsp/
|
Request for Question Clarification by
aht-ga
on
15 Feb 2004 19:51 PST
lizardnation-ga:
One software quality approach that has been gaining some loyal followers is Scrum:
Scrum Rules
http://www.scrumalliance.org/start_rules.php
Unfortunately, this approach has really only taken root in certain
parts of the United States, for now. For a small team of six people,
though, this approach may be the most palatable, as foremost among the
Scrum Rules is the concept of 30-day sprints, where management sets
the objectives, and at the end of the sprint the team produces an
executable that meets the objectives. Coupled with new processes for
the sake of efficiency (as opposed to simply for the sake of
"quality"), the philosophy behind Scrum is that good software
development approaches (including proper documentation) will result
from the desire to code for speed. Almost a contradiction to the
traditional view that speed = shortcuts = improper documentation and
techniques.
Another benefit of the Scrum approach is that it requires trust. Trust
between management and developers, and trust between the developers
themselves. I suspect that the developers already trust each other, so
the real benefit will be developing trust between the developers and
management.
|
