Indus University

Assignment
Professional Practice
Q-1: What are the different types of Software companies? Explain their working mechanism

and targets with examples? (3)

Q-2: Explain in detail the different structure of any software companies with their role and
advantages? (3)

Q-3: What is the importance of contract? Explain in detail the role and importance of the
clause section of any contract related with a computer company example? (3)
Ans 1)
IT companies can be broadly classified into two as service-based companies and product-based
companies.

Service-based companies
Service-based companies are one of the types of IT company, who do not provide any service or
product directly to end-users in their brand. Instead, they work for other clients. These are the
companies which will recruit from normal colleges in our state. In most cases, these companies will
never demand that only computer science or information technology students should attend their
interview. Instead, they will make the interview process open for every department including civil and
mechanical and select the required. There are also some cases where you will be recruited by these
companies and your joining date will be only after one year.

Once you are in the job they will give training as per their needs for around three months. They will
only put into the job after some tests based on the training. In the training also, you will not be
trained to the core level but to use some common tools and APIs developed by other product
companies. The job will be also a kind of repetitive job with less learning and not keeping up with the
latest technology. There is also a period called bench on these types of companies where the
employees will spend their time idle in their campus due to unavailability of the project. These
companies usually use to be very strict on office timings and dress code like that.

The package offered by these companies to a fresher is around 3 to 3.5 lacs per annum. You will be
getting an approximate amount of 21,000 – 26,000 in hand per month after all deductions. Service-
based companies example: TCS, Wipro, Infosys, Accenture, Cognizant, Tech Mahindra etc.

Product Based Companies:

Product-based are those companies who will be working on their own products and deliver that
product to the end users. They will look for candidates who have good technical and domain
knowledge and is familiar with the latest tools and technology. They will mostly hire students who
had their specialization for their requirement. In most of their interviews, at least one round will be by
the team who has a requirement on a special skillset. They will analyze whether the candidate meets
their requirement and fits their team. They use to spend time on recruitment in only IITs, NITs or
some premium institutions as they have to send a team for an interview in working day paying their
costs, where they will be able to get more students.

In product-based companies, you work on the same product for years while in service it will be
mostly for some months (years in rare cases). In most cases the product-based companies consider
their employees as an asset for their company as losing them will be a great loss as it will take more
time for a new employee to expertise their product. Product based companies will consider the
quality as the King while the service-based consider the client as King. There you will have more
opportunities for learning as you will have a new problem and write code from scratch
The average salary in a product-based company will be around 12 lacs per annum. Even many non-
established start-ups use to pay a minimum of 6 lac per annum. They won’t be that much strict on
timings, you just have to do your work. Product based companies example: Apple, Microsoft,
Google, Facebook etc.

Ans 2)

HARDWARE & SOFTWARE COMPANY ORGANIZATIONAL

STRUCTURE :
Hierarchical/Functional/Centralized – the classic organizational style of traditional businesses.
The strength of this type of organization is that it is easier to optimize each function, as there are
more resources available within each function in a centralized approach. This can enable a more
sophisticated approach to best practices. On the downside, I remember well the frustrations of my
first job with a Big 3 Automotive manufacturer, which was VERY hierarchical and centralized. The
company was SO hierarchical that it paralyzed the organization to a huge degree. Trying to get even
the simplest, small thing done had to go many levels up. It was like trying to turn a battleship on a
dime and was really painful. I’m not a big fan of this org structure style for larger and complex
companies, but for smaller, single-market or single product companies, it generally is optimal.

Decentralized/Autonomous Business Units – This is the polar opposite of the traditional

hierarchical organization. It’s my preference for a growing software company organizational structure
which is starting to “spreading their wings” beyond their initial market or technology focus, as well as
for larger companies. It’s strength lies in the ability to keep lines of communications short, keep
personnel close to the marketplace and motivate self-starters by providing more positions of broad
responsibility. For medium-sized companies, the danger lies in decentralizing before there is really
critical mass to run separate business units, which comes with some added costs due to duplication
of functions, as mentioned above. One good way to mitigate this is at least initially is to centralize
and share as many of the non-product specific functions as possible, such as finance, HR, quality
control, etc. The key functions that absolutely need to reside in the business units are usually
marketing, product development, possibly manufacturing (for hardware companies) and occasionally
sales.

Product-Centric or Market-Centric– This is a variation that can be combined with either of the two
major types of IT or software company organizational structure discussed above. For example,
within your marketing department, there could be people assigned to product lines as product
managers, or to market segments as market managers. Sometimes a hybrid approach is used,
where there are product managers for unreleased products, and market managers for currently-
marketed products.

Matrix – This organization style is “overlaid” on top of a more typical organizational structure, such
as the types discussed above. The main idea is to set up “dotted line” teams, responsibilities and
reporting structures that are desirable, but fall outside of the normal way a team is organized within
the main structure in use. For example, in a hierarchical organization, you might set up a matrixed,
cross-functional team to put focus on the launch of an important new business initiative or product
line. This may give the new initiative more emphasis than it normally would get, given what might be
seen as its its modest importance to the overall business at that point. If used properly, matrix
management organizational techniques can be a great way to dampen the negatives that are
inevitable in any rigid organizational structure. It must be used with caution, however. If used too
frequently, or without endowing the “head” of the matrix with real power to accomplish the desired
goals, matrix organizations can quickly become ineffective and politically driven entities–and the butt
of jokes around the water cooler.

Ans 3)
Contracts provide a written document that outlines the full understanding of the business relationship
and scope of the work so that no one can claim any misunderstandings later down the road. They
specify exactly what rights are being purchased and what rights you're retaining. They're binding and
legally enforceable.

Nearly all IT projects require some sort of procurement, whether it is for hardware, software, or
services. Therefore, IT project managers need to understand the major element of IT procurement
contracts, as outlined in this post.
IT managers make two common mistakes in regards to contracts. First, they often treat contracts as
legal matters only and delegate contract review to corporate legal counsel. Although legal review is
essential, lawyers often do not have the technical or operational background to evaluate IT contracts
from a business perspective. A lawyer may not anticipate what could go wrong in a software
implementation, nor might he or she think to recommend a clause specifying, for example, the
buyer's right to request a change in the vendor's personnel at no charge within an initial time period.
Procurement contracts are too important to delegate to the legal department alone. Instead, read
through every contract from a business perspective first, and then route the contract through the
legal department for final review.
Second, IT managers are often too conservative in their approach to requesting changes to contract
language. Vendors of IT products and services generally have their own boilerplate agreements,
which they present to buyers as their "standard contract." Many project managers assume that such
contracts are not easily modified. This is a mistake. Such boilerplate language almost always favors
the seller, and any contract is an agreement between two parties. The buyer has as much right to
suggest language for the agreement as the seller does. Never assume that contract language is cast
in stone.
Please note that the information provided in this report is not to be construed as legal advice. Each
procurement contract requires legal advice from a competent lawyer to ensure that it is appropriate
for the buyer's situation.

Typical Contract Elements

Understanding procurement contracts begins with a knowledge of what such contracts have in
common. The Uniform Commercial Code (UCC), created in 1951, established eleven articles that all
U.S. states (except Louisiana) follow. (Since Louisiana's legal code is based on civil law and not
common law, the state has elected to only follow some of the UCC articles.) All commercial
procurements are subject to UCC code--except for government contracts, which fall under the
Federal Acquisition Regulation (FAR) rules. Figure 1 shows the major sections that generally exist in
all contracts. These sections may not appear in the same sequence in all contracts, or they may
appear under different headings than those shown, but they generally appear in most procurement
agreements.

Let us review each of these main sections.

● The statement of work defines the scope of the agreement. It is a complete description of the
work to be done and the requirements to be satisfied under the procurement. It generally
appears early in the contract. For example, the contract for a new computer server might
include a statement of work that specifies the scope of the contract, including delivery and
complete installation of the new equipment.

● Following closely after or combined with the statement of work are item specifications. If the
supplier is to build or provide a tangible product, the specification is the definition of the
technical requirements for the product being procured. Generally there are three types of
specifications found in contracts. First, design specifications describe the problem to be
solved or the requirements to be fulfilled by the product. Second, functional specifications
 describe what the product must do. It is the blueprint for the design of the product from the
user's perspective. Finally, performance specifications provide an understanding of the
required level of performance for the product, including specific metrics and tolerances.

● Under UCC Article 2-513, the buyer has the right to inspect the goods prior to making
payment. The inspection must be made in a reasonable amount of time to allow the seller to
make adjustments if necessary. Therefore, it may be prudent to set up a schedule of specific
dates for testing and inspection in the contract, especially if these activities will take place at
the seller's location. Reasonable penalties can be established for failure to comply.

● Whether the vendor is supplying the customer with one item or multiple items, having a
delivery schedule in the contract holds the vendor accountable to the customer's project
timeline. The contract can also specify penalties on the seller for failure to meet delivery
schedules.

● Warranties can either be expressed or implied. UCC Articles 2-313 and 2-314 discuss each
type of warranty. An express warranty, one which is spelled out in the contract, is stronger
than an implied warranty, which is generally assumed in procuring products and services of
the type under consideration. The warranty section of the contract may also disclaim any
warranties express or implied.

● It is important to establish governing law within the contract. If the contract is between two
parties within the United States and one party is not a U.S. government agency, then the UCC
articles will govern the contract. If the seller's home base is outside of the U.S., it is prudent to
have language in the contract detailing which governing body's law and regulations will control
the contract.

● The order of precedence section sets forth the rank order of procurement documents in the
event that there are conflicts in the language of individual documents. For example, in the
procurement of a software application, the buyer may generate a request for proposal (RFP),
the seller may prepare an RFP response, and the two parties may ultimately agree on a
procurement contract. The order of precedence clause of the contract may then specify that
the contract terms and conditions override the RFP, and the original RFP overrides the
seller's RFP response.

● The title transfer section lays out the details for when and if title passes from the seller to the
buyer for the items that have been procured. For example, a contract for 500 new personal
computers might specify that title transfers to the buyer upon completion of testing.

● Companies always have the right to terminate a contract for a "default" in performance, which
is a form of breach of contract. To protect the buyer's interests, it may be wise to have a
clause which allows the buyer to terminate a contract for its own convenience. For example, a
contract might specify that either party may terminate the contract with 30 days written notice.
Or, termination may only be permitted in the event of a serious breach in performance. A
termination section should also include what rights and responsibilities are to continue in the
event of contract termination, such as the need to protect the trade secrets that may have
been disclosed during the course of the relationship.
● Arbitration is usually less costly than litigation but considerably more costly than mediation. If
arbitration is will be used to settle disputes, an arbitration clause should be inserted in the
contract specifying the intent of all parties, like whether the arbitration will be voluntary or
binding.

● Charge-backs are generally costs that the rightful responsibility of the seller--such as to repair
defective items--but which by prior agreement will be incurred by the buyer and charged back
to the seller. The charge-back section may also include a definition of what charges may not
be charged back to the seller.

● The payment schedule defines the terms and conditions for the buyer's payments to the
seller. For example, the payment schedule for a custom-developed system may call for a
certain amount to be paid up front, with another amount due upon delivery, and final payment
due 30 days after completion of user acceptance testing. There are many ways to pay for
goods and services.