If a tree falls in the woods and no one hears it, did it really make a sound? This question is at the heart of the need for people who help training reach students. It’s only by helping students through the course that it has had any impact or value. There’s no good in a course that sits on the shelves, never to be used. Distribution staff, of which instructors are a part, are the bridge from the completed training to the impactful implementation.
The phrase most likely to describe the author in the training and development process is “and then the magic happens.” The author is at the core of the content development process. He or she takes the input from the SMEs and the coaching from the learning designer and makes it happen.
When SharePoint first came out in 2001, development for the platform wasn’t easy. It was ASP—not ASP.NET, which was the first development approach for SharePoint. In 2003, the platform was migrated to .NET, but it wasn’t until 2007 that it had a proper customization strategy in the form of features and solutions. The world has changed since then, and SharePoint has had several development models come—and one has both come and gone. In this article, we’ll look at the development models available in SharePoint and Office 365 development and explain why one would choose one model versus another.
I’ve been developing software for more than 25 years now. I’ve learned dozens of platforms and frameworks. I expect, at some point, the process of learning a new platform will get easier. Each time it does, to some degree, but it’s never enough.
Twelve years ago, when I wrote the first articles for “Cracking the Code: Breaking Down the Software Development Roles,” I made a conscious and perhaps controversial decision to not include the database administrator or a database architect as a part of the roles. The decision was made because there were few organizations who dealt with the scale of data that required this dedicated role in the software development process. The solution architect could take care of the organization’s need to design the data structure as a part of their overall role. However, the world of data has gotten bigger since then.
Human brains are amazing things. They’re power-hungry biological machines that consume 20 to 30 percent of the blood’s glucose while being only two to three percent of the overall mass of the body. As complex engines for our cognition, it’s no surprise that we need people who are specifically focused on the tuning of these powerful engines. Those specialists are learning designers, also called instructional designers. These brain mechanics have a set of tools in their internal toolbox that allows them to identify how to improve the brain’s performance in new and novel areas.
Since we don’t have the ability to read minds, enabling us to learn quickly from experts, we must settle for subject matter experts (SMEs), who can help us understand what employees need to learn to reach the desired outcomes and how to sequence that training effectively.
Any training process starts with a business need. That is, someone in the business wants or needs their employees to be more productive than they currently are and looks to training or a job aid to generate that productivity. The business owner is that person, who starts the process of improving productivity.
There’s a lot of attention on new delivery models, the desire to create shorter courses and the attempt to apply metrics to the training process. However, relatively little is being said about the fundamentals of the content development process. While there are absolutely differences in the way content is generated from one medium to another and from one organization to another, there are more similarities than there are differences. This article is the first in a series that will walk through the roles in the process, including how the process fits together and how the individual roles add to the result.
It’s been nearly a dozen years since I first wrote “Cracking the Code: Breaking Down the Software Development Roles” and the associated specific role articles. The world has changed substantially in the last dozen years, but strangely, relatively little has changed in the roles for software development—except in the transformation of the deployment role into what is now being called “DevOps”—a contraction of Development-Operations. In short, we’ve changed how we operationalize the deployment of our code into our environments and into customer systems. It’s time to address the changes that have come to the world of software deployment.