Hire a Mercenary CTO  For Startups and Scale ups

Blogs

Using Azure DevOps to Manage Global team

We started using DevOps (formally TFS), over the last two years, we have seen the many improvements, and we have tried to expand the use of the suite of tools as they have come along.

Today, I want to tell you about how to use DevOps from a project management standpoint describing a project management aspect of an iterative process with Agile characteristics.

  • To begin, I’ll choose the Agile template from Azure DevOps, and I’m going to build work items.
  • Let me explain the hierarchy of work items to understand them. We have epics, features, user stories, then tasks and hours (which live at a task level). Here’s an example to help:
  • Let’s say I want to analyze sales. To do this, I’ll use epics and to analyze sales correctly, and I need to add features to my epics.
  • If I want to analyze the profitability of my sales or analyze my customers based upon sales, I will add features for this.
  • To build out a feature, we need to have user stories. If my feature is, I want to analyze customers based upon sales, and I’d want to capture data about my customers or my products and a point of sale day for my user story.
  • Now, what tasks do I need to deliver a good user story? Tasks are where your hours. This is where you estimate; you do an original estimate, then you show the hours completed and the hours remaining to be worked.
  • If I want to capture data about my customers, that user story would be built out by tasks like: design the customer dimension, create a data source for the customers, verify the source to target mapping, create the ELT for the customer dimension and certify customer data.
  • Not all the tasks above need to be completed by the developer. Some of them, like certify the data or verify the source to target mapping, may be done by your clients. The key here is by developing user stories at the task level, and it allows you to involve the whole team.
  • Another essential aspect to discuss bugs. When a user story has a bug, maybe there’s a code issue or a requirement was missed; it’s important to capture information using the bug work item type, and you'll want to manage your bugs in ways that align with your Agile practices.
  • By using DevOps for project management, the built-in reporting for burndown charts and Sprint planning allows you to properly communicate with your management and clients about reasonable expectations for you and your development team. It provides up to the minute reporting, so everyone is fully informed.
  • Testing is a critical area for any DevOps team, we use inline tests for lightweight traceability and to manage manual tests for user stories or other backlog items that they support. Our issue is that there is no integrated automated way to test mobile application iOS and Android within DevOps, oh boy, would this be a nice to have. So we have to create manual test cases to check deliverables to meet user needs.

How to Take Better Notes

I created this document for my kids to help them at school. But I have been to a lot of meetings in the last several years and I am shocked at how many people especially the younger group cannot take notes. I hope people will find this useful. Please make suggestions for improvements to the doc.

illustration of the Cornell note taking method with a 2.5 inch cue column on the left hand side, 6 inch note taking area on the right hand side, and a 2 inch high summaries area on the bottom

The Note Page

Note Taking Area: Record lecture as fully and as meaningful as possible. 

Cue Column: As you're taking notes, keep the cue column empty. Soon after the lecture, reduce your notes to concise jottings as clues for Reciting, Reviewing, and Reflecting. 

Summaries: Sum up each page of your notes in a sentence or two. 

This format provides the perfect opportunity for following through with the 5 R's of note-taking: 

Record 

During the lecture, record in the main column as many meaningful facts and ideas as you can. Write legibly. 

Reduce 

As soon as possible, summarize these facts and ideas concisely in the Cue Column. Summarizing clarifies meanings and relationships, reinforces continuity, and strengthens memory. 

Recite 

Cover the Note Taking Area, using only your jottings in the Cue Column, say over the facts and ideas of the lecture as fully as you can, not mechanically, but in your own words. Then, verify what you have said. 

Reflect 

Draw out opinions from your notes and use them as a starting point for your own reflections on the course and how it relates to your other courses. Reflection will help prevent ideas from being inert and soon forgotten. 

Review 

Spend 10 minutes every week in a quick review of your notes, and you will retain most of what you have learned.

http://www.arc.sbc.edu/images/arrow.gif

Note Taking Skills
Evaluate Your Present Note-Taking System

Ask yourself: 

  1. Did I use any form at all? Are my notes clear or confusing? 
  2. Did I capture the main points and subpoints? 
  3. Did I streamline using abbreviations and shortcuts? 
http://www.arc.sbc.edu/images/arrow.gif

If you answered no to any of these questions, you may need to develop some new note-taking skills!

Five Important Reasons to Take Notes 

  1. It triggers basic lecturing processes and helps you to remember information. 
  2. It helps you to concentrate in class. 
  3. It helps you prepare for tests. 
  4. Your notes are often a source of valuable clues for what information the instructor thinks most important (i.e., what will show up on the next test). 
  5. Your notes often contain information that cannot be found elsewhere (i.e., in your textbook). 
http://www.arc.sbc.edu/images/arrow.gif

Guidelines for Note-Taking 

  1. Concentrate on the lecture or on the reading material. 
  2. Take notes consistently. 
  3. Take notes selectively. Do NOT try to write down every word. Remember that the average lecturer speaks approximately 125-140 words per minute, and the average note-taker writes at a rate of about 25 words per minute. 
  4. Translate ideas into your own words. 
  5. Organize notes into some sort of logical form. 
  6. Be brief. Write down only the major points and important information. 
  7. Write legibly. Notes are useless if you cannot read them later! 
  8. Don't be concerned with spelling and grammar. 
http://www.arc.sbc.edu/images/arrow.gif

Tips for Finding Major Points in Lectures

The speaker is usually making an important point if he or she: 

  1. Pauses before or after an idea. 
  2. Uses repetition to emphasize a point. 
  3. Uses introductory phrases to precede an important idea. 
  4. Writes an idea on the board. 
http://www.arc.sbc.edu/images/arrow.gif

Forms of Note-Taking 

  1. Outlining

    I. Topic sentence or main idea
    A. Major points providing information about the topic
    1. Subpoint that describes the major point
    a. Supporting detail for the subpoint 
  2. Patterning: flowcharts, diagrams 
  3. Listing, margin notes, highlighting 
http://www.arc.sbc.edu/images/arrow.gif

Ways to Reduce and Streamline Notes 

  1. Eliminate small connecting words such as: is, are, was, were, a, an, the, would, this, of course. Eliminate pronouns such as they, these, his, that, them. However, be careful NOT to eliminate these three words: and, in, on. 
  2. Use symbols to abbreviate, such as:

    +, & for and, plus
    = for equals
    - for minus
    # for number
    x for times
    > for greater than, more, larger
    < for less than, smaller, fewer than
    w/ for with
    w/o for without
    w/in for within
    ----> for leads to, produces, results in
    <---- for comes from
    / for per

    For example:
    "The diameter of the Earth is four times greater than the diameter of the Moon."
    Becomes:
    "Earth = 4x > diameter of the Moon." 
  3. Substitute numerals with symbols, for instance:

    Substitute "one" with 1
    Substitute "third" with 3rd 
  4. Abbreviate:

    Drop the last several letters of a word. For example, substitute "appropriate" with "approp."
    Drop some of the internal vowels of a word. For example, substitute "large" with "lrg." 

Listening Skills

A lecturer's value can be extracted only through listening. But listening is not the same as hearing. Listening is a conscious activity based on three basic skills: attitude, attention, and adjustment. These skills are known collectively as triple-A listening. 

  • Maintain a constructive attitude
    A positive attitude paves the way for open-mindedness. Don't assume from the outset that a lecture is going to be dull. And even if the lecturer makes statements you don't agree with, don't decide he or she is automatically wrong. Don't let reactive interference prevent you from recalling the speaker's key points. 
  • Strive to pay attention
    You cannot attain concentration by concentrating on the act of concentration. Your attention must focus on the lecture. When you hear a lecture, the words enter your short-term memory, where they have to be swiftly processed into ideas. If they aren't processed, then they will be dumped from short-term memory and will be gone forever. Attentive listening makes sure the ideas are processed. 
  • Cultivate a capacity for adjustment
    Although some speakers clearly indicate what they intend to cover in their lectures, you need to be flexible enough to follow a lecture regardless of the direction it may take. If, however, you are thoroughly lost, or if the speaker's messages is not coming across and you need to ask a clarifying question, do so.

Concentration

THE PROBLEM 

In many colleges over 30% of the students report problems concentrating on their studies. Most of these students blame outside distractions for their problems. Many research studies manipulating noise levels and distractions have found that such disturbances may increase, decrease, or not even affect concentration. These researchers have therefore concluded that distracters don't cause concentration problems directly. It is the way the distractors are interpreted by the students that disrupt their study. 

CREATING A STUDY ENVIRONMENT 

  1. Find a place to study and keep it for study only. 
  2. Tool-up the environment with all study needs. 
  3. Control noise level and the visual environment to acceptable levels. 
  4. Avoid relaxing while working; create a work atmosphere. 

WHEN TO STUDY 

  1. Best during the day and early evening; you'll remember better. 
  2. Best when there are fewest competing activities in progress. 
  3. Best when adequate rest periods are provided. 
  4. Stop studying when fatigue or lack of attention occurs. 

HOW TO STUDY & CONCENTRATE 

  1. When distractors are present, they become intensely involved. 
  2. Keep a pad of paper handy to jot down extraneous thoughts that cross your mind while studying, get them out of your mind, and on to paper. 
  3. Set study goals before you begin each period of study (number of pages, number of problems, etc.). 
  4. Design adequate rewards after specified goals are attained. 
  5. Break up the content of study by mixing up subjects and building in variety and interest and removing boredom. 
  6. Make the most of rest periods-do something quite different. 
  7. Don't try to mix work and play. 
  8. Start with short study periods and slowly build to longer periods only as fast as you maintain concentration. 
  9. If necessary, make a calendar of events to clear your mind of distractions. 
  10. Plan the length of your study period by the amount of material you have decided to cover, not by the clock. (Often the clock is one of the most serious distracters.)

The SQ3R Method for Thorough Study

Step 1: SURVEY 

Skim through the book and read tropical and subtropical headings and sentences. Read the summaries at the end of chapters and books. Try to anticipate what the author is going to say. 

WRITE these notes on paper, in sequence; then look over the jottings to get an overall idea or picture. 

Step 2: QUESTION 

Instead of reading paragraph headings such as "Basic Concepts of Reading," change to read, "What are the Basic Concepts of Reading?" These questions will become "hooks" on which to hang the reading material. 

WRITE these questions out; look over the questions to see the emphasis and direction; then attempt to give plausible answers before further reading. 

Step 3: READ 

Read with smoothness and alertness to answer the questions. Use all the techniques and principles demonstrated in class. 

WRITE notes, in your own words, under each question. Take a minimum number of notes - use these as a skeleton. 

Step 4: RECALL 

Without looking at your book or notes, mentally visualize and sketch, in your own words, the high points of the material immediately upon completing the reading. 

Step 5: REVIEW 

Look at your questions, answers, notes and book to see how well you did recall. Observe carefully the points stated incorrectly or omitted. Fix carefully in mind the logical sequence of the entire idea, concepts, or problem. Finish up with a mental picture of the WHOLE. 

NOTE: More time should be spent on recall than on reading.

Symbols

Using symbols helps students save time when taking notes. They are quick to write and take up less space than the much longer words they represent. Some examples of symbols include: percentage (%), question (?), number (#), and money ($). For practice, have students come up with symbols for the following words: and, equals, star, sun, and circle. You can then dictate mock sentences including these words and have the student write each sentence using abbreviations. For example, you might dictate the sentence, "Jack has a question about problem number one and would like an answer!" The student might write, "Jack has a ? about problem #1 & would like an answer!"

Abbreviations

Abbreviations, or shortened versions of longer words, help students break down words into smaller chunks of letters. Some examples of abbreviations include: Wednesday (Wed), homework (hwk), people (ppl), and school (schl). Students can feel free to make up their own abbreviations - there are no set rules for abbreviating most words! For example, he or she can choose to abbreviate therefore as thfr, maybe as mbe, or assignment as asmt. Students can be as creative as they like, so long as they remember what the abbreviations stand for. For practice, have students come up with abbreviations for the following words: Thursday, workbook, problem, notebook, and lesson. Then dictate sentences integrating these abbreviations for extra reinforcement. Work with the student to associate the abbreviation with the full word.

Contractions

Contractions save students time by combining two words into one shorter, more compact word. Some examples of contractions include: couldn't (stands for could not), he's (stands for he is), and hasn't (stands for has not). Have students come up with contractions for the following words: you are, is not, it will, and they are. For a bonus practice session, dictate sentences containing symbols, abbreviations, and contractions. Your students will be writing shorthand in no time!

The notes

Once students have mastered shorthand techniques, they must learn how to integrate these symbols, contractions, and abbreviations into well-organized notes. What is the best way to organize a well-written page of notes? That answer depends partially on the specific learning style of each student. Learning disabled students, in particular, may have a preferred learning style: some are more linear learners, while others are more visually-oriented. Linear learners will likely take an affinity towards Column-Style Note Taking, while visual learners will more likely prefer Webbing. Students should try both styles of note-taking to see which one works best.

Column-Style Note Taking

Column-Style Note Taking helps students organize information that they hear into two different columns. The left column should be drawn 1/3 from the left side of the page, and the right column should be 2/3 from the right side of the page. The student should label the left column "Main Ideas" and the right column "Notes." He or she should pre-prepare 3-4 pages of notes (depending on what grade the student is in and how complex the lecture is) using this column-style set-up.

In class, when the teacher begins speaking, the only place on the page where the student should take notes is on the right side, under the "Notes" column. During class, nothing should be written under the "Main Ideas" column on the left. When the student comes home from school, he or she should re-read the notes and group different sections of the lecture into specific main ideas. For example, if the entire lecture was on World War I, the first part may have been about causes of World War I. Thus, the student would write "Causes of World War I" on the left side of the page, under the "Main Ideas" column, next to the information corresponding to that section of the notes. The student would move through all of his or her notes in that manner, categorizing the notes into different main ideas. A sample of this style of note-taking might be as follows:

Main IdeasNotes
Causes of WWILeaders' aggression ↑ing nat'lism Economic comp. 
Battles of WWIBattle of Liege Battle of Frontiers Battle of Lorraine Battle of Mons 

Column-Style Note Taking encourages students to look back at their notes at the end of the school day to ensure that they understood all of the information from the lecture and that there were no information gaps. If there are any holes in the notes, students can either ask their teacher or a friend for the missing information or research that information in their textbooks. Students who have difficulty identifying the topic and main idea of a passage or lecture may practice this skill in isolation using written passages. They should read several passages and highlight the topic in blue, the main idea in green, and important details in yellow. The more students practise this process, the easier it will be for them to identify these key elements, and the easier it will be for them to take notes in class. Column-Style Note Taking is a very comprehensive strategy for taking notes and preparing well for upcoming exams.

Webbing

Webbing is a great strategy for students who prefer a more visual technique for taking notes. Many students who are dyslexic love this technique as it uses their ability to visualize. To use this strategy, students first draw a circle in the center of their page. Inside that circle, they write the topic of the lecture (for example, World War I). Next, they draw a line branching out of the center circle. On the line, they write the first section, or main idea, of the lecture (for example, Causes of World War I). They then draw bubbles branching out of that line containing important details that describe that main idea.

Once the teacher has finished discussing that section, students draw another line branching out from the original center circle. On that line, they write the next main idea (for example, Battles of World War I). They then draw bubbles branching out of that line with important details describing the main idea, and continue with that pattern until the lecture is complete. Webbing helps students visualize information that they hear or read, and serves as a great tool for test preparation. An example of a web diagram might be as follows:

Example web diagram

The process of listening in class and taking well-written notes can be an anxiety-filled activity. Students will be required to take more and more complex notes as they progress through school. Learning these techniques for shorthand and different styles of note-taking can ease this process and help students develop confidence in their own classroom abilities.

ITIL Availability Management

This case study is focused on availability management and how it fits into service delivery and support. ITIL by definition is an entire library of best practices. Progressing through the case study, some ITIL processes are covered very lightly, primarily to illustrate the inter-relationship of all the process areas. This is done to focus on availability management, not discount the other process. Every ITIL process area needs to be addressed for a complete solution.

CASE STUDY: ITIL Availability Management

About the IT Service Provider

The case study used to illustrate ITIL implementation is a service provider that self-assessments rank medium to high in readiness and moderate in integration between processes. An automated service desk (a renamed help desk) is in operation but does not have access to configuration, service level or known error resolution. Change management automation is in place but does not receive input automatically from the availability, problem and capacity management processes. Note: this case study has been ‘sanitized' to remove identifiable customer information.

For this case study, the focus is on implementation beginning with the availability management process. ITIL does not specify where implementation should start. Many organizations choose to focus on incident or configuration management. The techniques used in the case are adaptable to multiple process areas. The key to ITIL is the utilization of the three Ps (people, process and products). Each of these will evolve as we progress through the example.

Assigning Availability Management Activities and Responsibilities

The first task is to examine the organizational structure to begin defining and communicating ITIL responsibilities. This organization is arranged by function, with matrixed project responsibilities. This is the case study organizational chart:

Figure 1 - Example IT Service Provider Organization

Previously a group of availability management activities was generated. These included:

  • Determining availability requirements
  • Identifying vital business functions
  • Identifying the impact of a loss of vital business functions
  • Designing for expected levels of availability
  • Defining appropriate levels of security
  • Producing an availability plan
  • Collecting, analyzing, maintaining and reporting availability data
  • Monitoring availability KPIs
  • Monitoring SLA and OLA targets
  • Monitoring external supplier serviceability achievements
  • Conducting root cause analysis of availability incidents

From these, a list of more specific responsibilities/ tasks was generated. In this list, a suggested area of responsibility for the task has been included. This is organization dependent and typically negotiated with individual departments.

  • Ensuring that the availability management procedures are reviewed semi-annually and updated as needed. [Infrastructure/Availability]
  • Providing an incident management process that gathers availability management data [Automated Operations]
  • Maintaining a level of expertise in current and emerging technologies supporting availability management. [Infrastructure/Availability]
  • Supporting activities to increase the number of available metrics that can be included in customer SLAs. [Infrastructure/Availability]
  • Conducting a gap analysis of IT project configurations and proposes solutions to limit or avoid single sources of failure. [Infrastructure/Availability]
  • Implementing additional availability metrics. [Infrastructure/Availability]
  • Architecting availability management concepts into projects at the earliest opportunity and ensuring availability architectures are presented to the technical review board [Infrastructure/Availability]
  • Implementing automated availability management tools. [Infrastructure/Availability]
  • Ensuring that system documentation is updated as needed. [Infrastructure/Availability]
  • Establishing policies and procedures to collect and report availability data, such that a report of availability performance as it relates to the customer SLA and/or PSLA can be consistently prepared. [Operations]
  • Operating and administering of automated availability management/monitoring tools. [Automated Operations]
  • Serving as the first response staff (tier 1) for recording and resolving incidents. [Service Desk]
  • Recording incoming incidents in the tracking system. [Service Desk]
  • Properly classifying incidents with their availability impacts, according to established definitions. [Service Desk]
  • Resolving incidents within their area of responsibility. [All/Shared]
  • Recording the time service was restored on automated service tickets closed by the service desk. [Service Desk]
  • Escalating the incident according to established procedures when the incident cannot be resolved. [All/Shared]
  • Reviewing agreements with internal and external suppliers to ensure operational level agreements and underpinning contracts support the SLA requirements outlined in the customer contract.[Supplier Contracting]
  • Reviewing customer SLA requirements as documented by the Project Manager/Customer Relations Manager (PM/CRM) to ensure availability management risk is minimized. [Customer Contracting]
  • Ensuring that all systems are scanned for security vulnerabilities when system availability is restored. [Security]
  • Ensuring that members of staff are aware of and follow this policy and have received availability management training for the projects they support. [CTO/CIO]
  • Monitoring the progress of incidents to ensure completion, timeliness, and thoroughness. [Service Desk]
  • Monitoring availability incidents to ensure rapid continuity of operation planning (COOP) implementation when availability SLAs are endangered, based on Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO). [CTO/CIO]
  • Obtaining the availability requirements in business terms from the customer. [PMO]
  • Producing the availability plan. [PMO]
  • Ensuring ongoing availability reporting to the customer. [PMO]
  • Initiating action when service levels are not met. [PMO]
  • Ensuring availability management procedures and requirements are reviewed and updated as needed. [PMO]
  • Knowing the relevant SLAs for availability management and other metrics for specific customers. [All/Shared]
  • Acknowledging, completing and documenting tasks on incidents assigned to them within established timeframes. [All/Shared]
  • Ensuring that a service ticket with details regarding the incident has been opened for any incident for which they perform tasks. [Service Desk]
  • Properly classifying incidents with their availability impacts, according to established definitions on service tickets they generate. [Service Desk]
  • When contacted regarding an availability incident where no service ticket has been opened, they should clarify to the caller that only availability incidents recorded as a service ticket will be utilized to measure availability performance. [All/Shared]

How departments fulfill these responsibilities and complete these tasks is typically left to them. A complete delegation would include establishing Key Performance Indicators (KPIs) for each item. This level of detail is beyond the scope of this article.

Measuring Availability KPIs

Examining the fundamental availability metric, the availability of a service, requires understanding and analysis of many of the related KPIs. Service availability is a percentage of actual availability divided by agreed availability multiplied by 100 over an interval of time, such as a month or a year.

But what does it mean for a service to be available? In this case study, the organization considered three granular levels to construct their customer SLAs:

  • System prompt availability
  • Process availability
  • Application/service availability

System prompt availability is the ability of a single host or node to respond to requests. This can be evaluated by initiating a telnet session or ICMP ping. This is a basic indicator that the system is "alive". However, this may not indicate a system is usable. This type of metric can typically be set very close to 100%. For example, in 1998, HP announced a program called "5nines:5minutes" based on system prompt availability of 99.999% in 1998. [Gartner 1998]

Process availability is the ability to detect specific processes running on a host or node. This can be evaluated on the host without network communication using a process command such as ‘ps' on Unix host. The evaluation can be positive or negative. For example, the system may be considered available if a process is not running. For example, an online mainframe application does not become available until a nightly batch update is complete. If the batch update is still running, the online system is not available.

Neither system prompt nor process availability has a simple evaluation for availability in a clustered or redundant configuration. Service may be available even if one or more servers are unavailable. With system prompt or process availability metrics an evaluation, often a manual one must take place to determine if a single node or component failure would impact availability. The key question is - can customers obtain the promised service?

This enters the realm of application or service availability. For example, the Ebay.com auction site search application is handled by a cluster of 50 servers [Cockcroft 2004]. A significant number of these physical servers could be unavailable without affecting service availability. Typical ways of measuring availability in this type of environment are with robots (systems generating automated simulations of activities) or monitoring of key activity or error log files.

Integrating Availability Management Activities and Responsibilities

Availability management in ITIL is wrapped around the incident life-cycle (see Figure 4). Before any incidents occur, availability management functions take place during service planning and design. During incidents, availability metrics are gathered. After incidents occur, availability data is collected and reported. When availability data is analyzed, improvements are introduced if SLAs are not met.

In the next section, a storyboard demonstrates how people, processes and products (the three ITIL Ps), integrate together when applied to an IT service. The italicized text was previously listed in the generated list of responsibilities and tasks. This IT service is the delivery of a high-availability J2EE web application platform hosting application code developed by the customer for the Medical Records Project (MRP).

Availability Storyboard

The MRP customer requests the IT service provider to host the MRP web application. The IT service provider assigns a project manager to develop project requirements, budgets and schedules for the implementation. Because the MRP deals with medical records, high availability is a central concern, and the customer budget can support their requirements.

The project manager meets with the customer to obtain the availability requirements in business terms. The availability requirements are provided to architecture so availability management concepts are included in the system design. Availability requirements also go to customer contracts, so they can be included in the SLA and hosting charges. System documentation is updated as needed by input provided to configuration management. During the procurement phase, IT reviews supplier contracts to ensure internal and external support contracts support availability requirements. Where necessary, IT implements and monitors automated availability management tools.

With input from service level management, the PMO produces an availability plan. The MRP customer and the IT service provider have agreed to an application-level availability of 99.9%, as measured by the functions of login, access a patient record, update the patient record and logout. When an outage occurs, medical care of patients can be affected, so it has a high impact to the business. The agreed cost is six times the standard hosting rate. However, for any month where the availability is below 99.9%, the IT service provider rebates that month of hosting service charges.

The application is about to enter the production phase. This typically represents the largest amount of time in a service life-cycle. This phase is cyclical; roughly following the do-check-act steps in the Deming PDCA wheel (Figure 2).

The story resumes just prior to the availability incident. During the operation and administration of automated monitoring tools, a sensor indicates MRP is unavailable. The automated response includes opening an automated service ticket and alerting the service desk and key support personnel (including suppliers). The service desk responds as tier 1 support, verifies the specific customer's availability SLA is impacted, confirms through change management that the outage is unplanned, validates the outage and assigns an impact according to established definitions. In preparation for service restoration activities, the last change applied to the application components is researched and documented in the incident ticket. For the MRP customer, these actions by the service desk are all that is required before escalation to the next tier of support. Despite this ending the first tier of support, the service desk continues as the central contact point regarding the incident.

Contracts with internal and external suppliers require a fifteen-minute response to an established conference bridge when the incident impacts the MRP availability SLA. As participants arrive, the service desk provides information regarding the outage, ticket and change, as well as coordinates activities by support staff. The service desk administers a service restoration checklist to triage and isolate the source of the outage. CTO/CIO staff monitors the outage resolution to assess whether the incident can be resolved within the SLA parameters and to evaluate the implementation of COOP/DR plans. Members of the support staff acknowledge complete and document tasks that are assigned to them. As tasks are completed, the outage is regularly validated using the method that originally indicated the outage. When service is restored, the service desk collects and records availability data and reassigns the ticket to the problem management function for root cause analysis. Security scans the configuration for security vulnerabilities that may have been introduced through the resolution process.

If availability data shows the MRP service had an outage(s) of 30 minutes this month, the IT service provider has met the availability component of the SLA. In the monthly availability report, the PMO calculates an availability of 99.93, based on providing 43,170 service minutes out of 43,200 service minutes available, with an agreed availability of 99.9%.

On the other hand, if availability data shows the MRP service had an outage(s) of 45 minutes this month, the IT service provider has not met the availability component of the SLA. In the monthly availability report, the PMO calculates an availability of 99.89, based on providing 43,155 service minutes out of 43,200 service minutes available, with an agreed availability of 99.9%.

When availability service levels are not met, the PMO initiates action to improve availability. This may include directing architecture to conduct a system gap analysis to determine if the system can be enhanced technically or ensuring staff have sufficient training in availability policies and are aware of customer SLAs. The specific action is usually determined by analysis of additional availability/outage metrics, such as how long it takes to diagnose or repair the underlying problem (MTTR) or how often an outage occurs (MTBF).

Summary

The primary objective of this article was to move beyond the framework provided by ITIL. A general understanding of the ITIL framework is introduced by the topics covered in the ITIL Foundation certification. Moving beyond requires entering the Practitioner level, beginning to design specific ITIL processes, in this case, availability management. When designing and performing ITIL process area tasks, an understanding of the breadth of all the ITIL processes. This is the area recognized by the ITIL Manager's Certificate.

In developing this topic, it was necessary to provide some ITIL background at the foundation level. This was followed by some background and practice within the availability management process. Using a real-world example of an IT service provider, customer and IT service, an ITIL availability management process was constructed. Once the process was designed, it was illustrated using a storyboard technique with activities from many of the ITIL processes involved to illustrate the interaction between them.

SDLC Development Cycles

sdlc1In Development process, ideally we follow the cycles start from designing from Design perspective then Tech perspective. After design is deemed to be valid and ready to start to worked on, then we're start doing implementation and verified by QA.

Those particular event can run parallel on different topic, but need to be follow up sequential for the same one. For instance, a feature of adding emoji for company App Chat [;-)] should be initialised by creating PDD and PTD first, then start the implementation. Yet, another feature such as feature to change company App layout can be started on design phase, even though the Emoji feature is still being implemented.

Product Design Document

On this particular phase, Product and Research Team are start documented their result of work producing the initial design of the Product

Product Technical Document

The second phase is from Development Team are start documented their proposed solution based on PDD

Implementation

After the design and solution is deemed to be enough to go, then we'll start implementing the solution

Quality Assurance

At the end of the cycle, all implemented features must be verified first before going released to used by users

Different Perspective of SDLC

Product Perspective

sdlc2Before we start development, there are several gates that needed to be passed in order to detailed specification. On overview, the step would be

  1. Offsite Meeting, these meeting involved most if not all Heads within Mapan to discuss OKR (Objective Key Resualts) and product more valid High Level Solution of their respective division
  2. Product Fair, is particular event where Product Team is doing some presentation about what kind of product would be the main focus on the particular quarter. This event main purposes is to gather Tech resources to work on particular product they put their interest to
  3. Product Weekly Sync, there are weekly meeting where all stakeholder and developer meet to talk more about release plan and detailing out the task

Based on Release Plan and Product Specs, there are 2 workflow related to that. One is going to `Research Branch` that is handled by UX Team. The other one is `Tech Branch` that will be handled by Tech Product Team.

 

Gateway

Company wide Phase

Offsite Meeting

This main objective of this meeting is to brainstorm about the OKR Company between Heads within Mapan. This meeting is expected to give more feasible valid OKR on each division as result

Gatekeeper CEO Analyst
Cycle / Cadence Semester
Role &

Responsibility

All Heads within Mapan
Requirement Plans, Supporting Data, Company OKR
Communication Channel Direct meeting
Docs Template Company OKR
Output OKR on Division Level
Decision Maker All Heads within Mapan, each will be the Decision Maker for their respective division / department

Product Phase

Product Weekly Sync

This particular meeting is to discuss about priority and detailing specification of initiatives. All stakeholder should be prepared supporting document and data, such as, but not limited to

  • Product Workstream
  • Cycle Planning
  • Product Design Document
  • Technical Roadmap

With all those prepared, within the meeting all concern should be raised so that the pre-development final plan is produced to answer Product, Tech, UX and Business User needs

Gatekeeper Product Manager
Cycle / Cadence Weekly
Role &

Responsibility

  • Product Manager, providing backlog to be discuss
  • Tech Lead, challenge the technical solution that may arise within Sprint Planning
  • Software Quality Lead
  • Software Engineer, give technical concern related to the backlog
  • Quality Assurance
  • Software Engineer in Test
  • UX
  • Product Business Intelligence Analyst, give advise and verify database design
  • Scrum Master, facilitate the process and make sure everyone have the same opportunity to voice their opinion within the meeting
  • DevOps, give operational concern related to the backlog
Requirement Product-side Docs

  • Workstream
  • Cycle Planning
  • Product OKR
  • Product Design Docs

Tech-side Docs

  • Technical Roadmap
Communication Channel Direct Meeting
Docs Template Product Design Docs
Output
  • Release Plan
  • Product Specs
  • Product Design Docs
  • Product Technical Docs
Decision Maker Committee

Tech Branch Phase

Backlog Refinement

Backlog Refinement is the event that have specific time slot available to be used within the sprint to refined Product Backlog. The main purpose of this specific event is to review whether the next backlog already meet the Definition of Ready or not

Gatekeeper Product Manager
Cycle / Cadence At least once per 2 weeks
Role & Responsibility
  • Product Manager, to present several backlog that will be developed in the near future. Ideally for next sprint only
  • Tech Lead, help SE to give technical concern related to the backlog
  • Software Quality Lead, help QA to give quality concern related to the backlog
  • Software Engineer, to give technical concern related to the backlog
  • Quality Assurance, to give quality concern related to the backlog
  • Software Engineer in Test, to give concern related to automated testing
  • UX, to explain User Interface Design
  • Product Business Intelligence Analyst, to give concern related to data-related stuff (Possible design & architecture, data that need to be captured)
  • Scrum Master, to facilitate the event
  • DevOps, to give operational concern that might be happens after the backlog released
Requirement Product Backlog
Communication Channel Direct Communication, JIRA Board
Docs Template Product Technical Document
Output Refined Product Backlog, Product Technical Document
Decision Maker Based on majority vote at minimum 60% of attendances (Committee)

Sprint Planning

Sprint Planning is the initial meeting that actually discuss about what to commit within the Sprint. Within this particular meeting, there will be technical discussion on how to achieve the goal. This meeting is one of the Scrum Ceremony that will be facilitate by Scrum Master

Before Sprint Planning on the start of each Sprint, several section of the PTD must be completed first in order to get more understanding about the anything that should be consider when planning for solution. This includes

  • Safety Requirements
  • Software Quality Attributes

Some of sections in PTD also need to be fill out during or right after Sprint Planning, such as

  • Security Requirements
  • Business Rules
Gatekeeper Software Quality Lead
Cycle / Cadence 2 weeks
Role &

Responsibility

  • Product Manager, providing backlog to be discuss
  • Tech Lead, challenge the technical solution that may arise within Sprint Planning
  • Software Quality Lead
  • Software Engineer, give technical concern related to the backlog
  • Quality Assurance
  • Software Engineer in Test
  • UX
  • Product Business Intelligence Analyst, give advise and verify database design
  • Scrum Master, facilitate the process and make sure everyone have the same opportunity to voice their opinion within the meeting
  • DevOps, give operational concern related to the backlog
Requirement Product Technical Document, Product Backlog
Communication Channel Product Technical Document, Direct Meeting
Docs Template Product Technical Document
Output
  • Detailed Solution
    • Software Design
    • System Architecture Adjustment
  • Scored Backlog
  • Sprint Backlog
  • Planned Task
Decision Maker Scrum Team (Tech Lead, SQ Lead, Engineers, Quality Assurance)

Task Planning

In Task Planning, all Software Engineer, Quality Assurance, SEiT and DevOps define their detail task that needed to achieve all the stories. Each detail task, or we usually call sub task, should be small enough to be finished within a day timeframe. The main purpose for this event is to define the smallest chunk to do, so that we can get the clear task list to do to achieve specific story or task.

PTD also need to be updated on Task Breakdown section

Gatekeeper Scrum Team (Tech Lead, SQ Lead, Engineers, Quality Assurance)
Cycle / Cadence 2 weeks
Role &

Responsibility

  • Tech Lead, help SE to breakdown story / task into several development-related sub task
  • Software Quality Lead, help QA to breakdown story /  task into several testing-related sub task
  • Software Engineer, breakdown story / task into several development-related sub task
  • Quality Assurance, breakdown story /  task into several testing-related sub task
  • Software Engineer in Test, breakdown story /  task into several automated testing-related sub task
Requirement Scored Sprint Backlog
Communication Channel Direct communication, Jira Board, Product Technical Document
Docs Template Product Technical Document
Output Sub Task per Story / Task
Decision Maker Tech Lead, Software Quality Lead

Development

This step is the where coding happens, which will include several process

  • Create Unit Test
  • Business Logic Implementation
  • Code Standard Review

Within Development, it’s also necessary to update the Product Technical Document as the development goes. The section that must be filled or updated within Development phase are, but not limited to

  • Design and Implementation Constraints
  • User Documentation
  • Hardware Interfaces
  • Software Interfaces
  • Communications Interfaces
  • System Features
Gatekeeper Technical Lead
Cycle / Cadence Daily
Role &

Responsibility

  • Software Engineer, doing the coding including unit testing and other best practice to implement
  • Software Engineer in Test, create test script to automate testing according to requirements
  • DevOps, start preparing for deployment and do preparation related to Ops
  • Product Business Intelligence Analyst, making sure the solution provide the proper data structure & architecture
Requirement
  • Prioritised Sprint Backlog
  • Detailed SubTask
Communication Channel Direct communication, Product Team Slack Channel, Screen Hero, Jira Board
Docs Template Product Technical Docs
Output Unverified Product Increment
Decision Maker Technical Lead, Software Architect

Testing

This step is when the Quality Assurance make sure that the unverified product increment is actually meet the specification and quality standard

Gatekeeper Software Quality Lead
Cycle / Cadence Daily
Role &

Responsibility

Software Engineer in Test, verify Product Increment by doing automated test

Quality Assurance, verify Product Increment by doing manual test

Requirement Unverified Product Increment
Communication Channel Direct communication, Jira Board, Product Team Slack Channel
Docs Template <any docs that need to be standardize>
Output Quality Verified Product Increment
Decision Maker Software Quality Lead

UAT

Include Demo to Affected User

This step is to enable user verification to the actual feature developed by the team

Gatekeeper Software Quality Lead
Cycle / Cadence At least once per 2 weeks
Role &

Responsibility

  • Product Manager, to facilitate the process
  • Business User, to verify the feature is fits with the requirements
  • Quality Assurance
Requirement Quality Verified Product Increment
Communication Channel Direct communication, Product Team Slack Channel
Docs Template <any docs that need to be standardize>
Output User Verified Product Increment
Decision Maker Business User, Product Manager

Release Preparation (Tech & Product)

This step purpose is to preparing build of specific release. This particular build should be verified by DevOps first before it’s considering ready to deploy

Gatekeeper Software Quality Lead
Cycle / Cadence At least once per 2 weeks
Role &

Responsibility

  • SE, to prepare Deployment Step
  • QA, to verify Deployment Step, Test Release Candidate
  • Infra, Hardware Preparation
  • DevOps, to prepare Deployment Script, Coordinate Hardware Preparation
Requirement
  • User Verified Product Increment
  • Confirmation from Product Manager to Release specific feature
Communication Channel Deployment Plan Docs, Direct communication, Slack channel
Docs Template Deployment Plan Docs
Output
  • Deployment Step
  • Release Candidate
  • Hardware Prepared
Decision Maker DevOps

Release (Tech & Product)

This step is when deployment happens. Currently deployment is handled by Software Engineer with Quality Assurance help to verify. Currently we’re going to cloud, so this step’s definition might be vary according to how we deploy

Gatekeeper Product Manager & Business User
Cycle / Cadence At least once per 2 weeks
Role &

Responsibility

  • DevOps, ensure the deployment process executed properly
  • IT Infrastructure, support DevOps to do deployment
Requirement
  • Deployment Step
  • Release Candidate
  • Hardware Prepared
Communication Channel Deployment Plan Docs, Slack Channel #deployment
Docs Template Deployment Plan Docs
Output Released Features
Decision Maker Software Quality Lead

Demo

Demo is done during specific event to publish the works of the latest release to anyone that related and interested to know more

Gatekeeper Product Manager & Scrum Master
Cycle / Cadence 2 weeks
Role &

Responsibility

  • Business User, attend to have more knowledge about released feature
  • Product Manager, arrange the event
  • Software Engineer, prepare the feature to be presented
  • Quality Assurance, prepare the feature to be presented
  • Scrum Master (optional), facilitate if needed
Requirement Released Features
Communication Channel Direct Meeting
Docs Template -
Output Feature Release Understanding
Decision Maker -

Retrospective

The event is conduct in the end of the sprint to look back and ask what works and not works in the previous sprint. Based on that, the team will make improvement commitment together and will be implemented on the next sprint in terms of improving process or product

Gatekeeper Scrum Master
Cycle / Cadence 2 weeks
Role &

Responsibility

  • Product Manager, give concern to and get feedback from Scrum Team
  • Tech Lead, give concern and discuss what next
  • Software Quality Lead, give concern and discuss what next
  • Software Engineer, give concern and discuss what next
  • Quality Assurance, give concern and discuss what next
  • Software Engineer in Test, give concern and discuss what next
  • UX, give concern and discuss what next
  • Product Business Intelligence Analyst, give concern and discuss what next
  • Scrum Master, facilitate the Retrospective and make sure every concern is followed up
  • DevOps, give concern and discuss what next
Requirement End of Sprint
Communication Channel Direct communication, Running Docs, Product Team Channel
Docs Template No Template, but result must be written on sharable platform
Output Scrum Team Improvement Commitment
Decision Maker Product Team, facilitates by Scrum Master

UX Branch Phase

Research Prioritization

A user journey is a series of steps which represent a scenario in which a user might interact with the solution we are designing. They can be used for 2 main things

  1. Demonstrating the way users currently interact with the service / website / product
  2. Demonstrating the way users could interact with the service / website / product.

Among others, the map usually consists of the user’s action steps, the emotion, the pain point and the channel.

Gatekeeper UX Research on User Journey Mapping
Cycle / Cadence Monthly
Role &

Responsibility

  • Product Manager
  • Researcher
Requirement
  • Release Plan
  • Product Specs
  • Product Design Docs
Communication Channel Product Design Docs
Docs Template Product Design Docs
Output
  • Product Design Docs
  • Research Backlog
Decision Maker A Product committee consists of Product and UX lead

Research Sprint Planning

UX design process is a series of solution development from research, (visual) design, prototype, test to deliverable measurement.

Gatekeeper Product Manager
Cycle / Cadence Biweekly
Role &

Responsibility

  • Product Manager
  • UX Designer
Requirement
  • Product Design Docs
  • Research Report
Communication Channel
  • Product Design Docs
Docs Template
  • Product Technical Document
  • Product Design Docs
Output
  • Product Technical Docs
  • Product Design Docs
Decision Maker Scrum Team

Samsung Buys LoopPay to counter Apple Pay

Samsung Electronics has acquired LoopPay, a U.S. mobile payments firm that could help it counter the Apple Pay obile payments system. LoopPay produces small add-on devices for smartphones that can transmit credit card information in conjunction with a mobile app. When the devices are held within a few centimeters of a traditional magnetic strip reader, the information can be sent wirelessly to make a payment. LoopPay's Magnetic Secure Transmission (MST) technology creates magnetic fields that simulate those generated with a magnetic strip, and effectively turns card readers into contactless payment devices without modifications. The approach differs from that of NFC (near field communication) used in Apple Pay, which requires retailers to have contactless payment terminals that can accept NFC signals. Massachusetts-based LoopPay claims its solution can work at about 90% of point-of-sale terminals in the U.S., which would give Samsung an advantage in mobile payments.

"NFC is currently only available in less than 10% of U.S. retailers despite NFC's mobile launch almost a decade ago," a Samsung spokeswoman said via email. "MST solves the merchant acceptance issue that has prevented other mobile wallet solutions from reaching mass adoption." While LoopPay doesn't require merchants to upgrade their checkout devices, it requires extra hardware for users -- a card or fob, small rectangular devices that can attach to a smartphone either by themselves or in a phone case. Apple's NFC mobile payments technology, on the other hand, is housed in the iPhone 6 and the Apple Watch. Apple Pay also works with apps on certain iPads. One of LoopPay's products is a US$59 smartphone case that incorporates the card and can also house drivers' licenses and other IDs. The idea is for users to leave their wallets at home, so all they have to carry is a smartphone. Samsung said LoopPay's executives will work closely with its mobile division, suggesting the technology could be incorporated into Samsung devices. News reports have speculated that its upcoming flagship Galaxy S6 smartphone could have a new mobile payments technology when it is unveiled at Mobile World Congress next month. The Samsung spokeswoman would only say that "details on device integration" would be announced in the near future.

Could Google Split UP? — Google+,

Google+, which launched in late June 2011, has consistently failed to meet expectations -- especially that a Google-owned social network could compete neck-and-neck with Facebook, the world's largest social network. While Google+ features, like Hangouts and Circles, have proven popular, the site itself hasn't gained the kind of user base that can take a real bite out of Facebook. "It's obvious that Google+ hasn't been the home run that Google envisioned when they launched it a few years ago," said Dan Olds, an analyst with The Gabriel Consulting Group. "They did, and are still doing, everything they can to push social networking traffic onto Google+, but it still hasn't turned into a credible Facebook, Twitter, or even LinkedIn competitor." Olds said that he doesn't expect Google to simply tear Google+ down to the ground, but he can envision the company putting more muscle behind features like Hangouts, possibly making it a stand-alone product.

"I think Google needs to concentrate on a particular feature of Google+, like Hangouts, and build a really outstanding tool that provides a great customer experience," said Olds. "With unique features, they could sidestep their competition by, for example, providing much better real-time communications than Facebook, while giving users a more flexible and robust experience than Skype." Patrick Moorhead, an analyst with Moor Insights & Strategy, said he doubts Google will give up on Google+ just yet, but he thinks it's a lost-cause for the company. "For the first time, I view [Pichai's} comments as they will eventually tear Google+ down," he added. "I get the sense that Google+ is over and has completely faded into the background.... Google+ is done." Zeus Kerravala, an analyst with ZK Research, agrees, noting that the company needs Google+ to tie its different products together. But the social network itself will become less of an attraction; features, like Hangouts, will come to the forefront. When asked whether Google+ will remain "one big product," Pichai replied: "I think increasingly you'll see us focus on communications [Hangouts], photos and the Google+ stream as three important areas, rather than being thought of as one area." Just before that, Pichai also noted that Google+ is more than just a social network for the company. It also serves as the glue between many of its products and services. Google+, he said, offers a common login and identity across its services. Google today declined to comment on Pichai's interview and what he meant about the future of Google+.

IBM Targets $40 Billion in Cloud & Other Growth Areas by 2018

BIG BLUE - International Business Machines, which ruled computing in the age of the mainframe, is targeting $40 billion in annual revenue from the cloud, big data, security and other growth areas by 2018. The aggressive target, set by IBM executives at the company's annual investor meeting in New York on Thursday, is the latest step for the technology giant towards emerging, high-margin businesses, and away from its previous strongholds in hardware and servers. The $40 billion will come from areas which IBM calls its "strategic imperatives," namely cloud, analytics, mobile, social and security software. That would represent about 44% of $90 billion in total revenue that analysts expect from IBM in 2018. Those businesses generated $25 billion in revenue for IBM last year, or 27% of its total $93 billion in sales. The company said it would shift $4 billion in spending to its "strategic imperatives" this year.

Revenue at IBM has gradually shrunk over the past three years as it sold off its unprofitable units in businesses such as low-end servers, semiconductors and cash registers. IBM Chief Executive Virginia Rometty has said she was happy to jettison revenue from such unprofitable businesses, which she dubs "empty calories." IBM revenue has now fallen for the past 11 quarters, while earnings growth has been sporadic. The company says its long-term plan is to hit "low single-digit" revenue growth and "high single-digit" growth in operating earnings per share. Last year IBM withdrew its long-term plan to hit $20 per share in operating earnings for 2015. IBM stood by its January forecast of $15.75 to $16.50 in operating earnings per share for 2015. Analysts expect $16.02, on average, according to Thomson Reuters I/B/E/S. But the company, which gets more than half its revenue from overseas, said the strong U.S. dollar would crimp sales by more than 6% this year. In January, it had expected a currency- exchange dent to revenue of 5% to 6%

Gogo Expects to Benefit from Rising Demand for In-flight Internet

Gogo Inc. (GOGO.O), an in-flight internet services provider, gave a full-year revenue forecast range that was largely above analysts' average expectation, driven by a surge in demand from commercial and business aviation clients. Shares of the company, which also reported a better-than-expected revenue for the fourth quarter, were up about 5% at $18.40 in premarket trading on Thursday. Gogo forecast revenue of $490-$510 million for the year ending Dec. 31, compared with analysts' average estimate of $491.5 million, according to Thomson Reuters I/B/E/S. Gogo gets more than half of its revenue from offering services and selling equipment to commercial aircraft customers in North America, but has been expanding that service overseas as well. The company, whose customers include American Airlines (AAL.O), Virgin America and Air Canada ACb.TO, has been spending more on the expansion, for connectivity fees and regulatory approvals. Gogo, which also has a business aviation business, said it expects to offer its services on 125 additional commercial aircraft outside North America this year, doubling its count from 85 at the end of 2014.

Still most of the growth in the fourth quarter was powered by the more profitable aviation business, where revenue from services exceeded that from equipment sales for the first time. Higher average monthly service revenue per aircraft in both its commercial and aviation businesses helped revenue rise 18% to $109.2 million in the quarter and beat Wall Street expectation of $106.3 million. The company, which has not reported a profit since going public in 2013, said its net loss widened to $24.1 million from $22.1 million a year earlier. However, the loss of 28 cents on a per share basis was smaller than the 31 cents analysts’ were expecting

Twitter Acquires Niche, a Social-media Talent Scout

Niche helps online stars on services like Vine to find advertisers. Twitter is acquiring Niche, a New York startup that matches social media stars with advertisers, helping Twitter tap into the lucrative world of Internet celebrity. Niche was founded in 2013 and helps hot creators on platforms like Vine, Instagram and YouTube to make money by matching them with brands that want to reach a similar audience. Niche has partnered with Twitter in the past, helping to create ads like this one for Hewlett-Packard on Vine.  Vine has become popular for uploading short videos and some of the most popular creators have millions of followers. Niche has served as a link between those creators and advertisers. By acquiring Niche, Twitter gains a talent agency for the digital age. Niche's service might also help Twitter's appeal to advertisers who want to reach a younger audience on new platforms. That could help Twitter to grow its crucial ads business.

"As more users and creators use different products as a way to share what's happening in their world, brands are also looking to partner with those individuals in hopes of generating moments that resonate with the people they are trying to reach," said Baljeet Singh, director of product management at Twitter, in the company's announcement.  Terms of the deal were not disclosed, though a report on Re/code cited a price of roughly $30 million. Twitter did not immediately respond to comment. Niche says it has more than 6,500 creators in its network including photographers, visual artists and fashionistas. It helps them earn revenue through its partnerships with more than 100 brands including Coca-Cola, Aetna and BMW. Niche also provides analytics services across desktop and mobile

 

Content Provider Publicis Groupe is in Talks to Acquire Press Agency Relaxnews

Content creator Relaxnews is a company that develops customized content and related technology for media, brands, e-commerce sites, blogs and company Web sites. The holding company said Relaxnews is valued at approximately $15 million euro (about $17 million at today’s exchange rate) based on the acquisition price currently being discussed by the parties. In addition to content creation, Relaxnews advises companies on content management and development. The firm is a Paris-based press agency and a member of France’s federation of press agencies as well as the International Press and Telecom Council. It employs about 100 staffers. Relaxnews has a partnership with Agence France Presse (AFP) and last year it launched a new platform utilizing that partnership that combines data, content and services for brands and media. Clients of the AFP-Relaxnews partnership, which focuses on lifestyle and leisure news, include Getty Images, Globo, Microsoft, Yahoo and others.

Assuming the acquisition is completed, Relaxnews would be aligned with Publicis Groupe’s global media agency network ZenithOptimedia, but also work with other units throughout the holding company. It’s expected that Relaxnews would retain its current management team under Co-Chairmen Jerome and Pierre Doncieux, who would report to Sebastien Danet, global managing partner at ZenithOptimedia. Danet said the acquisition would bring a firm with “unmatched expertise in today’s content revolution” into the Publicis Groupe fold. That expertise combined with the holding company’s digital offering, he added, “will transform media platforms for the benefit our clients.” Publicis Groupe CEO Maurice Levy said the acquisition would help the holding company’s clients to “better adapt their content for the digital world.”Subject to certain conditions, Publicis Groupe has an exclusive negotiating window that extends to May 31. The parties said they hope to reach a final agreement by April and complete it by June 30.