Sie sind hier: Home > Publisher > Guide for contributing

Writers Guidelines

Writers' Guideline Table of Contents Editorial Statement Editorial Focus What we're looking for...

Career-enhancing articles
Technical articles
How to submit articles
Send materials to... helpdesk@mcsemag.info
Payment or Compensation: none
Appendix B: Case studies

Editorial Statement

MCSE Magazine is the independent technical and career magazine for the elite IT professional and those responsible for managing infrastructure & personnel. We occupy a unique niche among magazines--no other publication is focused solely on the interests and concerns of Microsoft Certified Professionals.

Our readers are not necessarily Microsoft certified people. They are managers, consultants,government and university members, HR professionals, young professionals and many more.

Editorial Focus

MCSE Magazine provides our reader with technical, career, and professional development information in a single, easy to read source.

Information is supplemented with columns on technical tips and real-world experiences frompracticing MCPs. Recognizing that readers are inundated with monotonous technical detail, we strive to develop a "light" approach to our writing.

Subject:

Technical information
career-enhancing professional articles
certification and industry announcements
real-world solution experience sharing for Microsoft technologies.

Our audience ranges from the new Microsoft Certified Professional (MCP) to seasoned veterans with careers in system/network support, training, and application development.

In all cases, readers are assumed to have a high level of technical knowledge about Microsoft products, and about software and network technologies.

In general, articles should be as detailed as possible, within the constraints of the article’s length.

Achieving and maintaining certification
Certification news
Network and interoperability issues

Success stories:

MCPs successes with clients & employers
Migrating from one product to other products
Understanding and using Microsoft and third-party tools
Tips, tricks, tutorials and traps
Product reviews
Expert advice

Career-enhancing articles Articles on "soft skills" should assume a career development perspective. We want articles that will help others in the Certified Professional community gain maximum benefit from their skills and investment in certification.

Using certification to screen new employees
Marketing your services with certification
Incorporating certification into the corporate career development system
Certification and measurement of real world skills
"Soft Skills" development to complement technical skills
Tips on preparing for, and passing certification exams
Developing training for certification objectives
The software certification industry
How to find a new job using certification
How to get promotions and raises through certification
How to start a consulting business around certification
Trends in training and testing technologies
Using your MCP title in negotiating salary

Technical articles

Technical articles should emphasize a "case study" point of view and should share the most useful insights gained from real world experiences.

For example, it helps to provide a list of recommended resources or steps that will make the difference between success and failure.

Networking and Support Related topics:

Development Related
Windows 2000/.NET/XP family
Visual Basic
Windows NT Server
Visual Basic Add-Ons
Windows NT Workstation
VBA Windows 95 & 98
ActiveX Automation (formerly OLE Automation)
Microsoft Exchange Server Programming
Microsoft Office
Microsoft SQL Server
Microsoft SNA Server
ODBC
Microsoft Systems Management Server (SMS)
MAPI
Microsoft to NetWare Connectivity Access
Microsoft to Enterprise (Unix) Connectivity
FoxPro
Internet Information Server
Visual C++ & MFC
Other Microsoft Internet tools
Visual InterDev
Microsoft Office products

Note:

The best articles discuss using the above tools in combination with each other or some other popular platform or tool as part of a business solution. We also need other types of articles. Think about the things you’ve discovered. What are you glad you’ve learned?

We also run exam prep product reviews and stories about related third-party products ornew application development products and approaches to business solutions. We’re open to story ideas that can benefit users of any key products.

Appendix B:

Case studies

A case study is an opportunity to tell readers about a project in enough detail that they can learn concrete information to apply to their own projects. Case studies should highlight both the successes and failures encountered:

Did the project take longer than planned? Did several pieces of software fail to work together? Was a wrong choice made in terms of some of the pieces?

What would you do differently next time? What would you do the same? MCSE Magazine runs two kinds of case studies:

short, 1,000-word-or-less pieces called "e-solutions" that present a short explanation of a technical solution that the writer has implemented successfully, and longer pieces that may run up to 2,500 words.

A case study is not a chance for a consulting firm to advertise its services, nor for a product to be described in glowing terms--both sides of the story need to be told. Case Study Format Obviously, all of the following points won’t apply to every case study, and certainly not to short "e-solution" pieces.

But use the following outline to remind you of the details about the case study that you may want to include. Remember, you’re charting a path for others who will be attempting a similar feat with similar resources after reading your piece. (Bold lines indicate the most crucial information to include.)

The first paragraph of the story should not only draw the reader in, but should give a quick summary of what the "hooks" of the article will be: "When Company XYZ decided to migrate its Microsoft Mail system to Exchange, the IT department had no idea that the biggest challenge would be …"

I. What the system consisted of before
· Description of what it did
· Hardware and software
· Personnel involved with supporting it

II. Business problems
· Why change the system?
· Did management, MIS, or users need convincing? (Advice?)

III. Approaches considered
· Why discarded or accepted

IV. Personnel brought in to handle the job
· Why they were chosen (third-party party vs. in-house vs. new staff)

V. Systems to be created
· Goals

VI. Cost factor
· Current expenses
· Anticipated savings or expenditures

VII. Time Table
· How job was broken down
· Estimated time required for each phase

VIII. Software
· Software (server, app dev tools, backup system, audit, disaster recovery, tools)

IX. Hardware
· Network, PCs, backup, other

X. Configuration
· Physical location of equipment

XI. Development
· Prototyping
· Actual coding, or implementation

XII. Making the cutover
· Testing, QA, debugging
· Problems that surfaced
· Tricks uncovered

XIII. Business as usual
· Who handles support
· Who’s responsible for updating, problems, etc.

XIV. Reassess and review
· Do’s and don'ts for readers
· Surprises
· Unplanned benefits

X. Things you wish you’d done differently
· What’s next: strategic planning Back to Top