We're trying to plan for agile transformation soon, and one of the main sticking points in this is organizational structure. Management's expectation is to have a Scrum Master perform all normal functions, but tacking on hiring, firing, and performance reviews for people under his management.
Your company is not planning on transforming anything. They are planning to rename a role, which they hope will magically endow the project with the benefits of agile processes without going through the actual hard work of re-engineering the project management process, the corporate culture, or the organizational structure. This is extremely likely to result in epic failure for the project, blame for the team, and a blot on the resume for the putative Scrum Master.
A Scrum Master Isn't a Line Manager
The Scrum Master's job is to referee the Scrum process, educate the team and the organization about Scrum, and radiate information about the project to the Product Owner and the organization at large. While it isn't impossible to give a Scrum Master managerial authority, it actively works against the self-organizing principles that Scrum is meant to encourage.
A Scrum Master's primary role is often compromised when he's asked to manage individuals rather than act as a servant-leader for the entire team. An ideal Scrum Master is a spokesperson for the team, working with the Product Owner and the stakeholders to clear obstacles; cracking the whip isn't part of that job description.
Organizational Change is Hard
A lot of organizations attempt to label themselves agile, or say they've adopted Scrum, but they never actually change the fundamental business processes that underlie their projects. Scrum is a capacity-based framework that uses time-boxes to estimate and measure progress; it is not a magic bullet that can substitute for inspired leadership.
Adopting agile practices and frameworks is certainly a laudable objective. However, it takes more than a change of title and a new business card to restructure the role of Project Manager to Scrum Master. It also requires pervasive changes to the organization (especially among the stakeholders) in order to embrace the iterative development model. It also requires behavioral changes at the stakeholder and management levels to support the one project, one Product Owner model necessary for effective Sprint Planning.
Management Needs to Change, Too
Scrum isn't something that only development teams do. Adopting Scrum requires executives, stakeholders, and managers to change, too. The psychological shift from 100% utilization of individual team members to team-based capacity planning may ultimately defeat an organization that refuses to change its metrics or its management style.
For Scrum to be successful, senior management needs to make fundamental changes, too. If the "agile transformation" stops at the organizational boundaries of the development team, the Scrum implementation will not succeed.