:::: MENU ::::

Howk IT-Dienstleistungen

Howk IT Services – Howk IT-Dienstleistungen

Posts Categorized / pagex

  • Jan 27 / 2014
  • 0
pagex

5 Excuses SEOs Love to Use

Table of Contents

  • 1. The Algorithm Changed
  • 2. It Was a Manual SERP Edit
  • 3. They’re an Authority / Brand Site So They Can Do Anything They Want
  • 4. I’ve Seen This With Other Sites
  • 5. Matt Cutts Said So
No Excuses

SEOs, especially those providing consulting services, are often confronted with situations that they need to explain. They are, after all, supposed to be experts in the way search engines work and knowing why something has happened is why they get the big bucks, right? For those that have put their trust in an SEO, you’ve probably heard some crazy excuses and sensed a little CYA or BS. For future encounters, I’ve expanded on 5 of the more common excuses.

1. The Algorithm Changed

This is a good one. Since Google and the other search engines keep the details of their algorithms a secret, anyone can claim that there’s been a change knowing that there isn’t any way to disprove the statement.

Sometimes the explanation is legit especially when the word “algorithm” is used to denote any piece of data that the search engines use to determine ranking rather than the “core” algorithm that probably doesn’t change all that much.

If the algorithm has changed, then there should be noticeable changes on multiple sites since a change is highly unlikely to affect just one site. For example, Aaron Wall identified an algorithm change when he reported on Google’s preference for big brands.

2. It Was a Manual SERP Edit

When a decline in a site’s performance in organic search results is sudden, a manual SERP edit is often blamed. While it’s true that Google’s web spam team will manually evaluate sites and apply a penalty / filter if they discover something that violates their terms of service, if you aren’t doing anything particularly aggressive then a manual edit isn’t likely. If, on the other hand, you have crossed the line that Google has drawn in the sand, then a manual edit is quite possible.

There’s no foolproof way to distinguish between a manual edit and one that was algorithmic. The only advice I can provide is to assess what you’ve been doing, undo it, and if performance improves you were likely hit with an algorithmic penalty. If things don’t improve, that’s when you’ll want to submit a reconsideration request since a manual edit requires a manual review to correct.

3. They’re an Authority / Brand Site So They Can Do Anything They Want

The authority / brand explanation is the SEO’s lament when a competitor continues to perform exceptionally well. While never admitted to by the folks at Google, there’s a lot of anecdotal evidence that a popular brand can get away with more TOS-violating activities than a lone site owner.

There isn’t much you can do about this double-standard except to build a brand of your own. Since most of us don’t have that kind of budget, the alternative is to always proceed in a defensive manner — if you put all of your eggs in one basket you’re going to be in big trouble when Google knocks that basket out of your hand.

Even when a big brand is caught red-handed, there’s still a double-standard as reconsideration requests are actually attended to quickly.

4. I’ve Seen This With Other Sites

This explanation is sort of like social proof. If another site is doing something and is successful, then that alone is often reason enough for your SEO to suggest the tactic to you. Similarly, if another site is dinged for an activity then your SEO may be warn you against doing it. The problem with this sort of thinking is that you can’t know all of the details about what someone else is doing. What is being detecting as correlation between an action and an effect may not be causal — there could very well be 10 other activities that are responsible for the observed effect.

5. Matt Cutts Said So

The best is when Matt Cutts apparently said something in one of his videos. Yeah, Matt Cutts probably, maybe said something sort of related, but it’s next to impossible to track down the exact statement because the videos are too numerous and transcripts for all of them don’t exist.

The other complication with references to Matt Cutts are that Matt is a graduate of the school of Alan Greenspan explanations. At first blush everything sounds cool, but when you listen closely every answer prompts two more questions. No offense Matt, the information you provide is great and I certainly don’t expect you to give away the farm whenever an SEO asks.

By no means am I saying your SEO is lying to you when you hear one of the above excuses. Just be aware that sometimes such answers are based on a gut feeling and that asking for additional details might help both you and your SEO zero in on the real explanation.

  • Jan 27 / 2014
  • 0
pagex

Legal Issues in Consulting

 

 

In order to discuss liability that may arise under a consulting contract, you need to first understand two key terms.

Liability: Negligence occurs when someone directly harms someone else by failing to carry out a duty owed to them. To have liability, you need a duty, a breach of that duty, and resulting harm or injury.

Duty: Anyone who claims expertise in a field or area of study is obligated to meet a minimum industry standard of conduct towards others. In other words, they must follow the same standards of care, skill, and diligence that others with like expertise would normally follow in similar situations.

When a professional is engaged in assessing a problem; developing a solution; implementing a solution; or providing subsequent maintenance of the equipment and software, a breach occurs only when the level of care, skill, and diligence is less than that normally provided by members of the profession in good standing. Also, the law recognizes a bell curve of advice. That is, competent members of a profession can assess a problem differently and reach different solutions while still exercising a level of care, skill, and diligence required by the profession. It’s only when the level of effort or knowledge falls below the custom or standard that a breach occurs.

You need to be aware that when promises are made to clients, these promises create a legal responsibility so they should be considered carefully. When you claim expertise in an area and present information or recommendations as facts on which a customer relies, you and your employer can generally be held liable for the representation. Therefore, exercising care in what you promise and preparing a consulting agreement which carefully and clearly specifies the obligations, duties, and expectations of each party are among the best ways to minimize legal disputes around consulting engagements. It is always easier to meet goals and expectations when they are clearly defined and understood.

  • Jan 27 / 2014
  • 0
pagex

Solution Design Feasibility

When putting together an approach for addressing a client’s needs for your consulting services or when comparing the pros and cons of different solutions, there are several questions that you should consider when it comes to design feasibility. The following are an example of the minimum questions you need to pose to ensure a successful solution design.

Technical Feasibility

  • What business problems and client objectives will your solution address? Are these strategic or tactical in nature?
  • How important are these problems and objectives to the client?
  • Are there specific drop-dead dates to be met?
  • What might solutions are likely to work here? What are unlikely work?
  • How likely are the client’s executives willing and able to publicly commit to the goals and results you are proposing?
  • How much change, knowledge, and processes can the client absorb at once?
  • What demands can reasonably be made and sustained with those with responsibility for implementation?
  • Have you been in organizations like this before? What did you learn about the forces for and the forces against change in such organizations?

Financial Feasibility

  • What are the budget constraints for the engagement?
  • Where are there opportunities to influence and adjust the client’s perception of value?
  • What unique capabilities or advantages can you offer?
  • Is there a clear linkage to the goals and critical success factors for the organization?
  • Are you facing competition? What is the competition offering or likely to offer?
  • What is the engagement worth to the company in both the short-term and long-term?
  • What internal resources from the client’s side are available to devote to the engagement?

Operational Feasibility

  • How does the solution address the wants and requirements of each buying influence?
  • What are the risks associated with the engagement? How can the chosen approach be structured to mitigate these risks?
  • What implementation activities or responsibilities can the customer take on?
  • What implementation activities or responsibilities can be performed by subcontractors?
  • Jan 27 / 2014
  • 0
pagex

Waterfall (a.k.a. Traditional) Methodology

The waterfall model is a popular version of the systems development life cycle model for software engineering. Often considered the classic approach to the systems development life cycle, the waterfall model describes a development method that is rigid and linear. Waterfall development has distinct goals for each phase of development where each phase is completed for the next one is started and there is no turning back.

The perceived advantages of the waterfall process is that it allows for departmentalization and managerial control. A schedule is typically set with deadlines for each stage of development and a product can proceed through the development process. In theory, this process leads to the project being delivered on time because each phase has been planned in detail.

In practice, waterfall development often falls short of expectations as it does not embrace the inevitable changes and revisions that become necessary with most projects. Once an application is in the testing stage, it is very difficult to go back and change something that was not thought of in the concept stage. Alternatives to the waterfall model include joint application development (JAD), rapid application development (RAD), sync and stabilize, build and fix, and the spiral model.

If you’re looking to hire a project manager with a strong software development background, contact us and we will be happy to discuss
your company’s project needs and how we can address them.

  • Jan 27 / 2014
  • 0
pagex

ITIL Methodology

The Information Technology Infrastructure Library (ITIL) is a collection of best practices that aim to improve and then maintain a certain level of computing services quality in the information technology sector. ITIL covers organizational structure and skill requirements for an IT organization via a comprehensive set of procedures with which an organization can manage its IT operations. These procedures do not rely on a particular vendor’s technology and apply to all aspects of IT infrastructure.

ITIL consists of a collection of 7 books. The sets are sub-divided into disciplines, each of which is focused on a specific subject.

  1. Service Delivery: Covers the processes required for the planning and delivery of quality IT services, and looks at the longer-term processes associated with improving the quality of IT services delivered.
    1. IT Financial Management
    2. Capacity Management
    3. Availability Management
    4. IT Continuity Management
    5. Service Level Management
  2. Service Support: Describes the processes associated with the day-to-day support and maintenance activities involved in the provision of IT services.
    1. Change Management
    2. Release Management
    3. Problem Management
    4. Incident Management
    5. Configuration Management
    6. Service Desk
  3. Planning to Implement Service Management: Examines the issues and tasks involved in planning, implementing, and improving service management processes within an organization; also addresses the issues associated with addressing cultural and organizational change, the development of a vision and strategy, and the most appropriate method of approach.
  4. Security Management: Details the process of planning and managing a defined
    level of security for information and IT services, including all aspects of security incidents. Also includes the assessment and management of risks and vulnerabilities and the implementation of cost-justifiable countermeasures.
  5. Information and Communications Technology (ICT) Infrastructure Management: Covers all aspects of ICT infrastructure management from identification of business requirements through the procurement process, to the testing, installation, deployment, and ongoing operation and optimization of ICT components and IT services.
    1. Network service Management
    2. Operations Management
    3. Management of local processors
    4. Computer installation and acceptance
    5. Systems Management
  6. The Business Perspective: Provides advice and guidance to help IT personnel understand how they can contribute to business objectives and how their roles and services can be better aligned and exploited to maximize contribution.
  7. Application Management: Describes how to manage applications from the initial business need through all stages in the application lifecycle, up to and including retirement. Places emphasis on ensuring that IT projects and strategies are tightly aligned with those of the business through the application lifecycle, to ensure that business obtains the best value from its investment.

From the beginning, the ITIL framework has been publicly available (however, it is copyright protected). This means that any organization can use the framework described by the OGC in its numerous books. Because of this, ITIL guidance has been used by a wide range of organizations including government, energy, public utilities, retail, finance, and manufacturing. Very large organizations, very small organizations and everything in between have implemented ITIL processes.

  • Jan 27 / 2014
  • 0
pagex

PRINCE2 methodology

PRINCE2 Project Management Explained!

PRINCE2 Logo

PRINCE2 project management methodology is a process-driven project management method, which contrasts with reactive/adaptive methods, developed by Office of Government Commerce (OGC). PRINCE2 defines 45 separate sub-processes and organises these into eight processes as follows:

Starting up a Project (SU)

In this process the project team is appointed and a Project Brief (describing what the project is going to achieve and the business justification for doing so) is prepared. In addition the overall approach to be taken is decided and the next stage of the project is planned. Once this work is done, the project board is asked to authorise the next stage, that of initiating the project.

Planning (PL)

PRINCE2 project management method advocates product based planning which means that the first task when planning is to identify and analyse products. Once the activities required to create these products are identified then it is possible to estimate the effort required for each and then schedule activities into a plan. There is always risk associated with any work and this must be analysed. Finally, this process suggests how the format of plans can be agreed and ensures that plans are completed to such a format.

Initiating a Project (IP)

This process builds on the work of the Start Up (SU) activity and the Project Brief is then turned into a business case. The approach taken to ensure quality on the project is agreed together with the overall approach to controlling the project itself. Project files are also created as is an overall plan for the project. A plan for the next stage of the project is also created. The result can be put before the Project Board for them to authorise the project itself.

Directing a Project (DP)

These sub-processes dictate how the Project Board should control the overall project. As mentioned above, the Project Board can authorise an initiation stage and can also authorise a project. Directing a Project also dictates how the Project Board should authorise a stage plan, including any stage plan that replaces an existing stage plan due to slippage or other unforeseen circumstances. Also covered is the way in which the board can give ad hoc direction to a project and the way in which a project should be closed down.

Controlling a Stage (CS)

PRINCE2 project management method suggests that projects should be broken down into stages and these sub-processes dictate how each individual stage should be controlled. Most fundamentally this includes the way in which work packages are authorised and received. It also specifies the way in which progress should be monitored and how the highlights of the progress should be reported to the Project Board. A means for capturing and assessing project issues is suggested together with the way in which corrective action should be taken. It also lays down the method by which certain project issues should be escalated to the Project Board.

Managing Product Delivery (MP)

This process consists of three sub-processes and these cover the way in which a work package should be accepted, executed and delivered.

Managing Stage Boundaries (SB)

The Controlling a Stage process dictates what should be done within a stage, Managing Stage Boundaries (SB) dictates what should be done towards the end of a stage. Most obviously, the next stage should be planned and the overall project plan, risk log and business case amended as necessary. The process also covers what should be done for a stage that has gone outside its tolerance levels. Finally, the process dictates how the end of the stage should be reported.

Closing a Project (CP)

This covers the things that should be done at the end of a project. The project should be formally de-commissioned (and resources freed up for allocation to other activities), follow on actions should be identified and the project itself be formally evaluated.